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ABSTRACT 

One  certainty  for  the  future  of  warfare  is  change.  To  be  prepared  for  tomorrow's  new 
challenges.  Defence  requires  organisational  flexibility  and  innovation.  A  Joint  Synthetic 
Environment  (JSE)  may  facilitate  this  capacity  for  change  and  innovation  across  Defence.  A  JSE 
would  link  existing  and  emerging  synthetic  environments  such  virtual  air,  land  and  maritime 
platforms;  C4ISR,  EW  and  IO  simulations  developed  in  DSTO,  industry  and  by  our  allies 
through  the  use  of  interoperable  standards  and  simulation  services  based  on  High  Level 
Architecture  (HLA).  The  extension  of  the  Experimental  Command,  Control,  Communications 
and  Intelligence  Technology  Environment  (EXC3ITE)  network  to  support  the  use  of  distributed 
simulation  and  military  synthetic  environments  is  examined  from  a  corporate  research 
perspective.  Issues  from  operational,  systems  and  technical  perspectives  are  presented, 
addressing  the  use  of  emerging  simulation  middleware  (eg  HLA),  in  harmony  with  legacy 
simulation  standards.  Recommendations  are  made  for  progressing  the  development  of 
simulation  services,  which  will  require  a  response  from  industry  to  develop  as  a  National 
capability  to  underpin  future  military  experimentation  and  innovation  in  Australia. 
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Development  of  Simulation  Services  to  Support 
Military  Experimentation 


Executive  Summary 


"All  organizations  must  innovate  and  experiment,  or  they  will  lose  to  competitors  who  do." 
(Anon) 

"Our  capability  edge  will  also  come  from  innovative  ways  in  which  we  develop  our 
doctrine,  organization  and  logistics."  (Defence  White  Paper  2000) 

One  certainty  for  the  future  of  warfare  is  change.  To  be  prepared  for  tomorrow's  new 
challenges.  Defence  requires  organisational  flexibility  and  innovation.  A  Joint  Synthetic 
Environment  (JSE)  may  facilitate  this  capacity  for  change  and  innovation  across  Defence.  A 
JSE  would  link  existing  and  emerging  synthetic  environments  such  virtual  air,  land  and 
maritime  platforms;  C4ISR,  EW  and  IO  simulations  developed  in  DSTO,  industry  and  by  our 
allies  through  the  use  of  interoperable  standards  and  simulation  services  based  on  High 
Level  Architecture  (HLA). 

We  expect  that  future  Defence  simulations  will  be  component-based  with  open  interfaces, 
wrapped  by  "middleware"  (eg  such  as  HLA)  to  form  "simulation  services"  which  are 
available  to  any  authorized  user  on  the  network.  This  strategy  will  have  significant  savings 
for  Defence  in  terms  of  cost,  evolvability  and  ease  of  information  management. 

These  simulation  services  may  be  assembled  to  flexibly  integrate  synthetic  environments  as 
required  for  specific  Defence  studies.  The  knowledge  for  achieving  this  resides  in  the 
EXC3ITE  (Experimental  C3I  Technical  Environment)  experience,  and  we  propose  to  build 
these  simulation  services  with  EXC3ITE  information  services  to  facilitate  rich  military 
experimentation  and  innovation. 

We  examine  the  use  of  simulation  within  DSTO,  describe  an  operational  concept  and 
architecture  for  distributed  simulation  based  on  specific  "use"  cases  for  various  ADF 
environments,  and  also  address  a  number  of  systems  and  technical  issues  and  potential 
limitations. 

The  set  of  recommendations  will  be  addressed  by  the  DSTO  Simulation  Hub  to  progress  the 
development  of  this  capability. 
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1.  Scope  and  Vision 

One  certainly  for  the  future  of  warfare  is  change.  To  be  prepared  for  tomorrow's  new 
challenges.  Defence  requires  organisational  flexibility.  This  involves  working  in  adhoc 
coalitions  as  a  joint  force,  and  exploring  innovative  ways  to  conduct  operations 
through  the  development  of  new  operational  concepts,  doctrine,  processes,  and 
training.  A  Joint  Synthetic  Environment  (JSE)  may  facilitate  this  capacity  for  change 
and  innovation.  A  JSE  would  link  existing  and  emerging  environments  such  as  virtual 
air,  land  and  maritime  platforms;  C4ISR,  EW  and  IO  simulations  developed  in  DSTO, 
industry  and  by  our  allies  through  the  use  of  interoperable  standards. 

A  modelling  and  simulation  (M&S)  strategic  plan  has  been  developed1  which 
articulates  the  scope  for  support  to  improved  capabilities  and  decision  making  in 
Defence.  The  application  areas  for  simulation  pervade  all  dimensions  of  Defence 
activity  and  are  described  in  depth  in  Appendix  A.  They  include: 

•  capability  and  force  structure  analysis,  including  preparedness  and  resourcing; 

•  acquisition  including  systems  design,  development,  prototyping  and  procurement; 

•  individual  training  and  collective  single  service,  joint  and  combined  training; 

•  the  conduct  of  operations,  including  courses  of  action  analysis,  linking  strategic, 
operational  and  tactical  levels  of  command,  mission  planning  and  rehearsal;  and 

•  support  to  the  force  in  being  including  development  and  testing  of  doctrine  and 
tactics  and  systems  evaluation  and  improvement. 

Many  challenges  face  the  modelling  and  simulation  community  to  realise  these 
application  areas.  The  development  of  EXC3ITE  simulation  services  means  facing  the 
grand  challenges  of  the  integration  of  tools,  systems  and  data;  and  information 
management  for  the  simulation  community  as  described  in  Appendix  B.  These  areas  are 
already  core  to  EXC3ITE  from  its  established  role  in  the  C3I  community. 

Our  vision  to  drive  the  development  of  this  networked  environment  is  the  capability. . . 

"to  build  distributed  simulations  in  an  hour" 

To  build  a  complete,  and  complex  simulation  in  this  timeframe  implies  that  an 
authorised  user. . . 

•  is  able  to  easily  discover,  locate  and  access  all  necessary  data,  simulation  entities, 
and  tools  across  the  network; 

•  can  construct  systems  from  simple  to  use,  yet  rich,  interoperable  and  inter¬ 
communicating  component  entities,  data  services  and  tools; 

•  can  change  any  part  of  the  system  as  and  when  required; 


1  “Defence  Strategic  Plan  for  the  Coordination  of  Modelling  and  Simulation”,  Australian  Defence 
Headquarters,  June  1999. 
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•  can  be  blissfully  unaware  of  the  automatically-planned  and  managed  distributed 
execution  on  arbitrary  hardware  and  software  platforms;  where  the  integrity  of 
order  of  execution  and  quality  of  service  of  the  simulation  is  assured; 

•  can  rapidly  visualise  results  in  any  form  they  wish; 

•  can  reuse,  replay,  and  share  any  part  of  the  software  system  they  have  built;  etc. . . 

Computing  and  communications  has  the  potential  to  transform  the  nature  of 
simulation.  The  use  of  gigabit  data  rates  is  technically  feasible  now,  but  is  artificially 
(astronomically)  expensive  to  operate  in  Australia.  When  such  capabilities  are  within 
financial  reach  of  Defence,  distributed  simulation  may  operate  as  if  it  were  centralised. 
This  is  an  essence  of  the  impact  of  "deep  computing"  on  simulation  -  a  core  network  of 
high  power  computers  linked  by  fibre,  providing  a  new  level  of  richness  to  simulation. 
At  the  same  time,  the  growth  of  "pervasive  computing"  which  may  run  simulations  at 
the  periphery  of  the  core  network  connected  through  wireless  means  (eg.  on  personal 
digital  assistants  and  other  small  devices)  will  present  the  opportunity  to  bring 
simulation  closer  to  the  real  world.  This  will  have  a  profound  impact  on  the  reach  of 
simulation  to  the  level  of  the  individual,  with  the  new  opportunity  to  leverage  deep 
computing  and  simulation  services  from  the  core  network. 

The  purpose  of  this  document  is  to  guide  and  inform  the  EXC3ITE  project  and  its  users 
in  development  of  appropriate  distributed  simulation  services  to  support  the  DSTO 
R&D  community.  It  is  in  response  to  Takari  Executive  meeting  action  23/22. 

2.  Background 

Australia's  "Defence  Strategic  Plan  for  the  Coordination  of  Modelling  and  Simulation" 
was  endorsed  by  the  Defence  Capability  Forum  on  June  17,  1999.  The  Strategic  Plan 
includes  several  key  recommendations,  of  which  the  most  important  is  the 
establishment  of  the  Australian  Defence  Simulation  Office  (ADSO).  ADSO  was 
formally  set  up  within  Australian  Defence  Headquarters  in  February  2000.  A  key 
priority  for  ADSO  will  be  the  promulgation  of  a  Defence  Simulation  Master  Plan,  a 
draft  of  which  was  first  developed  in  1996/973.  In  addition,  ADSO  will  formulate 
directives  and  instructions  on  key  issues  such  as  standards  and  protocols  for  the 
networking  of  training  devices. 

The  development  of  information  networks  heralds  a  fourth  environment  for  military 
conflict,  augmenting  the  Air,  Land  and  Sea  environments.  The  Defence  Information 
Environment  (DIE)  is  the  Australian  Defence  information  network  providing 


2  ACTION  “Investigate  an  EXC3ITE  simulation  service,  including  architectures  for  simulation,  protocols, 
latency  and  bandwidth  issues.  Working  Group  to  include  Jason  Scholz,  Cliff  White,  John  Best,  Jon 
Vaughan,  Mike  Davies” 

3  ‘Ten  Year  Australian  Defence  Simulation  Strategy”,  P.D.  Clark,  LTCOL,  C.  Mazur,  pp  123-  129, 
Proceedings  of  the  Third  International  SimTecT  Conference,  SimTecT  98,  2-6  March  1998,  Adelaide, 
South  Australia,  ISBN  0-9585331-0-5. 
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information  to  commanders  and  Defence  managers.  The  DIE  incorporates  all  mobile 
military  elements  in  addition  to  headquarters  and  offices. 

The  Experimental  C3I  Technology  Environment  (EXC3ITE)  is  a  Defence  project 
(JP2061),  to  develop  and  leverage  the  use  of  middleware  in  the  Defence  Information 
Environment  (DIE).  Middleware  is  an  emerging  technology  evolving  from  current 
Internet  client-server  based  systems  towards  next  generation  Internet  multiple 
component  peer-to-peer  networks.  Middleware  provides  the  interface  between 
telecommunications  and  user  applications.  Middleware  may  be  considered  in  multiple 
layers.  Most  significantly  for  Defence,  the  "application-oriented"  middleware  layer 
consists  of  components  or  "information  services"  may  communicate  with  one  another 
and  be  assembled  as  required  to  effect  the  required  application.  With  an  investment 
focussed  on  interoperable  information  services  and  components,  the  need  for  costly, 
stove-piped  applications  is  expected  to  diminish,  and  the  dream  of  scalable 
information  management  will  be  realised.  The  benefits  to  Defence  of  middleware 
architectures  include  evolvability,  reuse,  scalability,  and  reliability,  and  thereby  offers 
significant  cost  savings  to  our  multi-billion  dollar  information  infrastructure.  The 
architecture  for  middleware  is  evolving  and  is  as  yet  unstable,  so  EXC3ITE  fulfils  the 
role  of  an  experimental  network  for  development,  test,  evaluation,  user  requirement 
elicitation,  and  user  experimentation  with  middleware  information  services.  EXC3ITE 
has  nodes  located  in  HQAST  and  AIO,  DSTO  Salisbury,  DSTO  Melbourne,  and  DSTO 
Fern  Hill  Canberra,  with  two  mobile,  field-deployable  units.  EXC3ITE  offers 
information  services,  which  include  geospatial,  track,  imagery,  visualisation,  C3I 
simulation,  enterprise-wide  database  query,  collaboration,  and  document 
management.  EXC3ITE  offers  these  information  services  for  use  by  synthetic 
environments,  and  along-side  other  simulated  and  live  systems. 

Figure  1  illustrates  the  role  of  proposed  EXC3ITE  information  and  simulation  services 
in  the  context  of  a  whole  of  Defence  strategy.  That  strategy  is  for  an  evolving  Defence 
capability  built  by  layers  of  depth,  providing  a  sustainable  competitive  advantage,  that 
could  not  easily  be  copied  by  Australia's  adversaries.  It  offers  a  vehicle  for  achieving  a 
common  technical  framework  between  real  and  simulated  systems  that  embraces  data 
standards,  common  conceptual  models  and  a  high  level  architecture.  Such  a 
framework  is  essential  to  the  component-based  approach  to  simulation  development 
and  assembly. 
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Figure  1.  A  strategy  toward  the  development  of  force  structure  options. 


The  story  of  warfare  is  the  story  of  technology,  however,  referring  to  Figure  1,  raw 
technology  alone  does  not  make  Defence  capability.  Raw  technologies  and  subsystems 
generally  offer  low  leverage  for  Defence,  and  weak  influence  on  the  organisation.  The 
Defence  Information  Environment  (DIE)  is  an  enabling  capability  to  allow  information 
to  be  harnessed  for  Defence  use.  The  systems  in  the  DIE  provide  Defence  decision¬ 
makers  with  access  to  information  and  knowledge  through  information  services  and 
applications.  This  level  has  been  the  focus  of  development  of  EXC3ITE  to  date.  An 
overlay  to  this  level  is  the  integration  of  synthetic  environments,  models  and 
simulations  and  real  systems.  This  level  is  the  focus  of  development  of  EXC3ITE 
Simulation  Services.  This  facilitates  R&D  in  a  mixed  service  environment  (eg.  Land-air, 
Maritime- Air,  Joint-Maritime- Air,  etc...),  forming  the  basis  for  innovating.  Through  the 
sharing  of  models,  simulations  and  information  new  forms  of  systems  (or  systems  of 
systems)  are  expected  to  emerge.  This  hierarchy  of  R&D  foundation  focuses  on  DSTO 
and  industry  developments,  and  is  the  enabler  for  the  hierarchy  of  military  innovation, 
which  follows.  Operations  refinement  and  training,  equipment  and  network 
operational  concept  development  would  imderpin  the  development  of  network- 
enabled  forces.  Building  on  these,  capability  development  and  smart  acquisition 
decisions  may  be  supported.  Deep  innovation  through  experimentation  with 
operational  concepts  in  turn  may  deliver  Revolution  in  Military  Affairs  (RMA)  ways 
for  Defence.  Lastly,  decisions  on  force  structure  options  at  the  whole  of  Defence 
portfolio  level  underpinned  by  the  deep  experiences  of  experimentation  may  facilitate 
a  strong  case  for  achieving  Strategic  Policy  and  political  ends.  All  of  these  areas  are 
relevant  to  and  need  to  be  supported  by  EXC3ITE  simulation  services. 
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Military  innovation  may  be  applied  throughout  the  life  cycle  of  a  capability,  as 
illustrated  in  Figure  2.  From  supporting  the  development  of  operational  concepts  in 
wargaming  through  to  mission  rehearsal,  the  applicability  of  such  a  service  may  be 
ubiquitously  applied. 
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Figure  2.  Network-enabled  warfare  supported  by  simulation  services  throughout  the  life  cycle  of 
a  capability. 
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Simulation  Related  Activities  in  DSTO 

The  following  diagram  illustrates  an  overview  of  the  current  state  of  synthetic 
environment  and  simulation  systems  development  by  Division. 
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Figure  3:  Simulation  related  activities  by  DSTO  division. 

The  development  of  simulations  in  DSTO  has  largely  been  independent  at  the 
divisional  level.  However,  each  division  does  have  a  unique  perspective  and 
requirements  for  their  client  areas  which  must  be  addressed  if  a  single  supporting 
environment  is  to  be  pursued. 

Air  Operations  Division  (AOD)  has  an  extensive  involvement  in  simulation  both  in  the 
constructive  and  virtual  areas.  The  development  of  AOD's  main  simulation  facility,  the 
AOSC  commenced  in  the  early  1990's  and  achieved  initial  operational  capability  (IOC) 
in  1994.  The  AOSC  is  continuing  to  be  developed,  particularly  in  the  software  area, 
while  at  the  same  time,  it  is  supporting  a  large  and  comprehensive  experimental 
program  in  HiL  simulation.  Work  carried  out  on  the  AOSC  includes: 

•  Evaluation  of  advanced  EW  warning  systems  in  rotary  wing  aircraft; 

•  Determination  of  safe  helicopter  operating  limits  for  shipboard  landings; 

•  Investigations  of  pilotage  of  rotary  wing  aircraft  using  night  vision  devices; 
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•  Investigations  of  helmet  mounted  sights  in  fast  jets;  and 

•  Demonstrations  of  advanced  distributed  simulation  concepts  to  support  air  defence 
controller  training  -  Virtual  Air  Environment  (VAE)  project. 

AOD  has  developed  a  large  range  of  relationships  and  interactions  with  both 
Australian  and  overseas  laboratories  and  organisations  involved  in  simulation.  These 
include: 

•  TTCP  JSA  TP-2:  Modelling  and  Simulation  and  AER  TP-1:  Aerospace  Simulation 
and  Operational  Analysis; 

•  US  Army,  CECOM,  Fort  Monmouth,  NJ  through  Project  Arrangement  10  (EW); 

•  US  Navy,  Battle  Fleet  Tactical  Trainer  (BFTT)  Project  on  distributed  simulation 
research; 

•  DGA,  France  through  MOU  on  HiL  simulation  with  helmet  mounted  sights; 

•  US  Air  Force  Research  Laboratory  (AFRL),  Mesa,  AZ  on  distributed  mission 
training; 

•  US  AFRL,  Dayton,  OH  on  "Virtual  Air  Commander"; 

•  Simulation  Industry  Association  of  Australian  (SIAA)  as  member  of  the  Executive 
and  involvement  in  the  SimTecT  Conferences  through  the  Technical  Committee 

•  RMIT  University  through  support  to  and  collaboration  with  students  involved  in 
postgraduate  simulation  studies. 

The  Air  Operational  Analysis  Branch  of  AOD  has  major  capabilities  in  constructive 
simulation.  Some  of  this  work  is  carried  out  on  large  simulations  models  sourced  from 
overseas  such  as  Thunder.  However,  during  the  past  few  years  much  effort  has  gone 
into  developing  the  BattleModel  architecture  and  the  BattleModel  is  currently  being 
employed  for  a  number  of  operational  analysis  (OA)  studies.  Other  areas  of  significant 
simulation  capability  within  AOD  include: 

•  Advanced  Distributed  Simulation  including  DIS  and  HLA; 

•  Detailed  6  DoF  simulations  of  fixed  wing  aircraft.  Fill,  F/ A-18,  etc; 

•  Detailed  6  Dof  simulations  of  rotary  wing  aircraft,  BlackHawk,  etc;  and 

•  Simulations  of  stores  release  from  aircraft  -  studies  employing  CFD  techniques. 

Surveillance  Systems  Division  (SSD)  subscribes  to  the  philosophy  that  simulation 
requires  a  team  of  three  different  types  of  expertise  -  domain  experts,  computer 
software  specialists  and  simulation  specialists.  The  division  is  replete  with  sensor 
technology  experts  and  a  small  core  of  software  and  simulation  specialists  interact  with 
them  to  provide  a  simulation  capability.  SSD  has  recently  demonstrated  an  ability  to 
model  integrated  surveillance  operations  at  a  medium  level  of  fidelity  in  support  of 
operational  assessment  studies.  It  was  achieved  by  exploiting  the  graphical 
specification  capabilities  (visual  formalism)  of  the  Simulink  and  Stateflow  simulation 
tools  from  the  MATLAB  stable.  These  tools  allow  the  physical  and  information  models 
to  be  assembled  readily,  implemented,  and  quickly  adapted  to  changing  requirements 
if  necessary.  A  formal  basis  (GAMBIT,  Gauss-Markov  Bayesian  Inference  Technique) 
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allowing  the  use  of  probabilistic  as  well  as  deterministic  simulation,  and  representing 
information  uncertainty  within  the  Integrated  Surveillance  Assessment  Tool  (ISAT)  has 
been  developed  and  is  being  implemented.  This  is  required  for  simulating  surveillance 
operations  where  there  is  a  need  to  model  information  explicitly.  These  developments 
together  with  the  high  fidelity  simulation  capability.  Virtual  Prototype's  STAGE, 
completes  a  suite  of  simulation  and  analysis  tools  referred  to  as  the  Integrated 
Surveillance  Assessment  Tool  (ISAT).  Cooperation  with  other  Divisions  will  enable  the 
addition  of  an  open  agent  infrastructure  to  STAGE  to  allow  use  of  a  variety  of 
intelligent  agents,  eg  Jack  or  Attitude,  in  high  fidelity  simulations.  Completion  is 
expected  within  two  months.  The  division  is  committed  to  providing  a  range  of  coarse 
and  detailed  surveillance  sensor  models.  A  number  currently  exists  eg 
JIINSIM(OTHR),  DCM(IR)  and  SBST(SAR). 

The  Information  Technology  Division  (ITD)  Joint  Synthetic  Environment  Facility 
(JOSEF)  has  a  range  of  capabilities  for  the  construction  of  C2-led  simulation  and 
synthetic  environments.  The  term  C2-led  refers  to  an  emphasis  on  modelling  of  and 
support  to  C2.  The  Distributed  Interactive  C3I  Effectiveness  (DICE)  simulation 
software  suite  is  a  key  component  of  the  JOSEF  and  LOD’s  SERF  and  TLCAC  facilities 
and  has  been  installed  with  SSD  to  aid  surveillance  systems  assessment.  DICE  has  been 
released  through  TTCP  JSA  TP2  (M&S)  in  support  of  collaboration  in  the 
interoperability  of  simulation  with  real  C2  systems.  DICE  has  played  a  key  role  in  LOD 
support  to  1  Brigade  and  the  CATDC.  DICE  enables  the  explicit  modelling  of  orders, 
reports  and  requests,  simulation  of  C2  and  C2  systems,  and  facilitates  interoperability 
with  real  C2  systems  through  semantic  and  syntactic  equivalence.  DICE  can  employ  a 
library  of  behavioural  models  implemented  using  a  range  of  intelligent  agent 
techniques,  interfaces  to  physical  domain  simulations  such  as  STAGE  and  JANUS,  and 
interfaces  to  operational  and  prototype  command  support  systems  such  as  BCSS  and 
the  Air  Asset  Visualisation  Tool  (AVT).  Interfaces  can  employ  a  range  of  protocols  such 
as  DIS  and  TILA.  The  modular  composable  nature  of  DICE  and  its  standard  internal 
language  has  seen  it  growing  as  the  de  facto  standard  for  C2  simulation.  DICE  has  been 
delivered  to  EXC3ITE.  The  JOSEF  and  its  tools  are  used  within  ITD  to  provide  M&S 
support  to  operational  planning  and  intelligence  with  key  customer  engagement  of 
DIO,  ASTJIC,  HQAST  and  a  vertical  slice  through  operational  and  tactical  Air.  Of 
particular  relevance  to  this  report  is  the  engagement  with  Surveillance  and  Control 
Group  and  simulation  and  synthetic  environment  support  to  air  asset  and  battlespace 
management. 

Theatre  Operations  Branch  (TOB)  is  developing  a  technology  base  ir.  operations 
research  including  modelling,  simulation,  and  gaming-based  methods,  tools  and 
techniques  to  support  Defence  HQ  and  HQAST  with  analysis  and  advice.  Using 
gaming  as  a  technique  for  learning  about  force  structuring  depends  on  being  able  to 
explore  conventional  and  innovative  operational  concepts.  Real-time  participation  of 
commanders  and  planning  staffs  engaged  with  current  or  emerging  analytical  tools 
over  EXC3ITE  will  significantly  improve  the  range  and  validity  of  the  judgements  that 
are  made  about  the  value  of  force  options  across  a  range  of  scenarios.  In  the  area  of 
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modelling  and  simulation,  TOB  has  acquired  a  capability  in  a  number  of  US  tools, 
including  JICM  (Joint  Integrated  Contingency  Model)  and  GCAM  (General  Campaign 
Analysis  Model).  In  addition,  TOB  has  developed  its  own  models  and  development 
tools,  including  TEMPO  (Theatre  Evacuation,  Movement,  and  Peace  support 
Operations  tool)  and  CAT  (Campaign  Analysis  Toolkit).  While  TOB  has  a  strong 
capability  to  produce  and  carry  out  analysis  based  on  these  and  custom  built  models, 
the  dearth  of  reusable  components  and  the  lack  of  a  deployment  infrastructure,  has 
considerably  slowed  its  efforts  to  give  life  to  these  models  through  visualisation, 
database  persistence  and  network-deployment.  Thus,  TOB  would  benefit  greatly  from 
any  system  that  would  provide  these  services  and  allow  TOB  to  concentrate  on  core 
model  development  skills. 

Weapons  Systems  Division  (WSD)  possesses  a  range  of  simulation  capabilities, 
which  include  simulations  of  missile  trajectories,  weapon  system  simulations,  and 
mission  simulations,  which  include  several  weapon  systems.  WSD  has  supported  the 
simulation  of  weapons  in  for  ADF  applications  such  as  the  F18  and  Fill  simulators  as 
well  as  DSTO  simulations  in  AOD,  and  MOD.  WSD  has  developed  a  missile-modelling 
framework,  which  is  being  used  for  missile  simulations  in  the  Air  Combat  Training 
System.  There  is  a  collaborative  program  with  TTCP  nations  developing  a  missile 
modelling  interface  specification.  Work  is  underway  on  the  development  of  a  virtual 
missile  laboratory  which  can  be  used  to  assess  the  impact  of  changes  to  algorithms  and 
software  in  a  computer  in  the  loop  environment  which  is  supported  by  a  suite  of 
analysis,  visualisation  and  validation  packages.  WSD  has  a  major  hardware  in  the  loop 
capability,  which  simulates  the  terminal  engagement  of  semi  active  and  IR  guidance 
systems.  A  major  upgrade  is  underway  to  extend  this  capability  by  adding  infra  red 
scene  generation  and  projection  equipment  needed  to  exercise  the  next  generation  of 
imaging  infra  red  seekers. 

Communications  Division  (CD)  has  established  a  Communications  Simulation 
Integrated  Product  Team  (IPT)  to  develop  reusable  communications  models  and  a 
framework  to  promote  the  rapid  construction  and  analysis  of  complex,  HLA-compliant 
models  of  deployed  communications  systems.  The  IPT  is  also  supporting  the 
integration  of  communications  models  into  constructive  simulation  and  virtual 
environments,  starting  with  the  SERF  in  LOD,  and  has  linkages  with  working  groups 
developing  other  synthetic  environments  in  DSTO.  The  IPT  membership  currently 
includes  the  Army  Engineering  Agency,  CD  and  LOD  but  is  expected  to  include 
representatives  from  most  divisions  of  DSTO  in  the  medium  to  long  term.  The  IPT  will 
be  expanded  in  the  near  future  to  include  Australian  industries  such  as  Darenmont, 
CSC,  Adacel,  Boeing,  DSpace,  Compucat  and  Motorola  who  have,  or  are  interested  in 
developing  OPNET  modelling  capability.  CD  is  also  collaborating  with  Boeing 
Australia  to  develop  an  OPNET-based  System  Performance  Model  (SPM)  for  the  High 
Frequency  Modernisation  Project.  External  collaborations  are  being  set  up  for 
exchanges  on  simulation  modelling  with  the  US  Joint  Staff  J6I  Network  Warfare 
Simulation  (NETWARS)  project  as  well  as  with  industry  (eg  SAIC)  working  on  the 
SMARTNETS  and  SEAMLSS  (Global  Mobility)  projects  sponsored  by  DARPA. 
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The  primary  focus  of  synthetic  environment  development  in  Maritime  Operations 
Division  (MOD)  is  the  Virtual  Ship  project.  The  Virtual  Ship  concept  calls  for  the 
integration  of  simulation  models  that  represent  the  component  systems  of  a  warship.  A 
virtual  representation  of  a  warship  is  thereby  constructed  in  a  manner  analogous  to 
construction  of  a  real  vessel.  The  primary  focus  of  the  program  is  support  of  real-time, 
human-in-the-loop  simulation.  It  is  intended  to  create  a  controlled  environment  where 
humans  may  interact  with  warship  systems  and  the  effectiveness  of  the  system  as  a 
whole  may  be  explored,  taking  account  of  the  human  component.  It  will  support  the 
acquisition  and  ownership  of  future  generations  of  naval  platforms  and  enhance  the 
effectiveness  of  the  force  in  being  through  its  contribution  to  tactical  development, 
training  and  mission  rehearsal.  It  is  particularly  envisaged  that  Virtual  Ship  will 
support  Project  SEA  4000.  In  addition,  opportunities  will  be  sought  to  use  Virtual  Ship 
to  investigate  combat  system  human  factors  aspects  and  investigate  the  role  of 
information  in  enhancing  operational  performance,  including  integration  of  C4ISR 
systems.  It  is  anticipated  that  the  Virtual  Ship  will  play  a  significant  role  in 
development  of  novel  warfighting  concepts,  such  as  network  enabled  warfare.  The 
High  Level  Architecture  forms  the  underlying  basis  for  the  Virtual  Ship.  Each  of  the 
simulation  components  is  compliant  with  the  HLA  and  this  facilitates  their 
interoperability  and  re-use  across  applications.  The  Virtual  Ship  project  draws  on 
significant  contributions  across  DSTO  divisions  and  industry.  WSD,  SSD,  EWD  and 
MPD  each  provide  simulation  components  from  within  their  domain  of  technical 
expertise.  In  addition,  a  significant  number  of  companies  have  been  engaged  in 
development  of  the  Virtual  Ship  Architecture,  through  the  mechanism  of  the  Virtual 
Ship  Architecture  Working  Group  (VSAWG). 

Other  synthetic  environment  activities  being  undertaken  in  MOD  include  the  Virtual 
Submarine  and  Virtual  Minehunter  Coastal.  The  Virtual  Submarine  supports  the 
evolution  of  the  Collins  combat  system  via  Projects  SEA  1439  and  SEA  1446.  The 
Virtual  Minehunter  Coastal  (VMHC)  supports  enhancement  of  the  MHC  tactical  data 
handling  system.  At  present  these  are  stand-alone  synthetic  environments.  It  is 
intended  to  move  down  a  path  whereby  these  interoperate  with  Virtual  Ship 
components  via  the  HLA.  Within  MOD  a  number  of  stand  alone  operational  analysis 
simulations  are  used.  These  are  typically  restricted  to  the  above  water,  underwater  and 
pro-submarine  operational  domains.  The  prospect  should  not  be  ruled  out  that  these 
may  find  use  as  scenario  generators  for  human-in-the-loop  simulation,  nor  that  they 
may  be  linked  to  create  scenarios  that  cross  current  operational  domain  boundaries. 
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ADF  Projects  and  Key  DSTO  Tasks  Related  to  Simulation 
Virtual  Air  Environment  (VAE) 

The  1997  Defence  White  Paper  placed  a  high  priority  on  the  ability  to  integrate 
surveillance  and  intelligence  information  to  detect,  track  and  identify  all  air  and 
maritime  targets  in  Australia's  northern  approaches.  A  number  of  systems  (JORN, 
AEW&C,  Air  Defence  Ground  Environment  (ADGE),  and  the  Air  Command  Support 
Systems  (ACSS)  are  being  acquired  to  meet  the  air  surveillance /airspace  control/air 
defence  component  of  this  capability.  Introduction  of  JORN,  AEW&C  and  a  modem 
ground  control  environment  will  require  a  considerable  increase  in  the  number  of 
active  Air  Defence  Controllers.  However,  the  number  of  F/A-18  missions  available  to 
support  ADCON  training  will  remain  static.  The  significant  investment  in  Air  Defence 
and  Airspace  Control  systems  must  be  supported  by  comprehensive  simulation 
systems  if  operators  are  to  maintain  an  acceptable  level  of  operational  capability. 

The  Virtual  Air  Environment  (VAE)  Project  aims  to  provide  a  framework  within  which 
RAAF  training  simulation  activities  would  take  place.  The  VAE  concept  would  have 
applicability  to  a  wide  range  of  ADF  simulation  systems,  to  the  evaluation  of 
operational  capabilities,  and  to  the  development  and  analysis  of  C4I  and  weapons 
systems.  The  VAE  concept  is  based  on  the  stimulation  of,  and  embedded  simulation 
within,  the  Air  Defence  and  Airspace  Command,  Control  and  Communication  System 
(ADAC2S),  which  will  be  operational  in  the  year  2001.  The  VAE  could  also  be  linked  to 
Army  and  Navy  simulation  systems  to  provide  a  common  environment  for  future  joint 
simulation  activities. 

The  Initial  Development  Phase  of  the  VAE  project  focuses  on  an  application  to  Air 
Defence  Controller  training,  which  integrates  real  assets  (RAAF  Williamtown  Air 
Defence  Controller  Consoles)  and  virtual  simulations  (comprising  Human-in-the-Loop 
(HiL)  and  computer  generated  entities)  in  one  environment,  to  create  a  cost-effective 
virtual  world  training  capability.  The  vision  is  to  extend  the  VAE  concept  to  the  entire 
Air  Defence  System  (with  similar  developments  in  the  Maritime  and  Land 
environments).  To  determine  the  structure  of  a  mature  VAE,  an  iterative  approach  of 
feasibility  demonstration  and  requirements  definition  is  being  used.  To  this  end,  a 
series  of  concept  demonstrations  are  being  conducted. 

In  the  first  VAE  demonstrations4  the  virtual  world  was  generated  at  DSTO's  Air 
Operations  Simulation  Centre  (AOSC)  at  Fishermans  Bend,  Melbourne.  The  AOSC  was 
connected  to  RAAF  Williamtown  via  an  ISDN  Wide  Area  Network.  Virtual  entities 
generated  at  the  AOSC  were  correctly  observed  in  the  RAAF  Williamtown  radar 
system.  This  demonstration  involved  linking  four  systems:  a  human-in-the-loop 


4  Pongracic,  H.,  Zalcman,  L.,  lob,  M.,  Craven,  D.,  Fulton,  J.,  Fernie,  M.,  Doman,  J.,  Clark,  P.,  Ryan,  P., 
Holland,  O.,  Jobson,  S.  and  A.  Robbie.  “The  Virtual  Air  Environment:  First  Demonstration”,  DSTO 
Client  Report  DSTO-CR-0160,  July  2000. 
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F/A-18  flight  simulator,  two  sources  of  computer  generated  entities  (BattleModel  and 
STAGE),  and  the  operational  Phoenix  display  system  for  Air  Defence  Controllers.  The 
first  three  provide  computer-generated  entities  that  stimulate  the  operational  Air 
Defence  System  to  provide  command  and  control  training.  An  Air  Defence  Controller, 
using  the  real  Air  Defence  System  at  Williamtown,  directed  the  pilot  of  the  F/A-18 
flight  simulator  in  Melbourne  to  intercept  virtual  (computer  generated)  entities  also 
produced  in  Melbourne.  All  entities  were  displayed  on  the  real  Air  Defence 
Controllers'  display  system  in  Williamtown.  Distributed  Interactive  Simulation  (DIS) 
networking  protocols  were  used.  Further  demonstrations  are  planned  to  stimulate 
JORN  using  computer-generated  entities,  and  linking  the  air  and  land  synthetic 
environments. 

RAN  Project  SEA  1412:  Development  of  Maritime  Warfare  Training  Sxjstem 

Through  Project  SEA  1412,  the  RAN  is  seeking  to  develop  the  Maritime  Warfare 
Training  System  (MWTS)  which  will  initially  link  several  existing  shore-based 
operations  room  trainers  with  a  wargaming  system  to  provide  enhanced  command 
team  and  tactical  training  for  the  RAN  into  the  21st  century.  This  system  will  provide 
training  for  the  two-ocean  based  Navy  (Sydney  and  Perth)  without  requiring 
expensive  collocation  of  assets.  The  MWTS  would  provide  manned  assets,  instructor 
supervision,  and  game  control  and  debriefing,  for  exercises  involving  both  live  and 
simulated  assets  across  a  large  synthetic  operating  area. 

In  later  phases  of  the  Project,  an  Australian  wide-area  maritime  simulation  network 
will  be  established.  This  system  could  include  ships  alongside  at  Fleet  Base  East  in 
Sydney  and  Fleet  Base  West  in  Western  Australia,  linked  via  their  on-board  training 
systems  with  the  systems  at  HMAS  WATSON.  Other  ADF  simulators,  such  as  RAN 
helicopter  simulators  and  RAAF  P3C,  FA-18  and  Airborne  Early  Warning  &  Control 
(AEW&C)  simulators,  may  also  be  able  to  participate  in  a  common  virtual  scenario  on 
an  opportunity  basis. 

The  approximate  timings  for  these  Phasings  are: 

Phase  2  -  2000  -  2002:  HMAS  WATSON  Simulators  -  current  and  approved 

•  Link  shore-based  systems  for  FFG/DDG/  ANZAC 

•  Provide  external  link  -  DIS /WAN  capability 
Phase  3  -  2004+ 

•  3A:  Proof  of  Concept  for  link  to  FFG  Ship 

•  3B:  Establish  interoperability  with  FFGs,  Nowra  helos;  P3C  (Edinburgh) 

•  3C:  Establish  interoperability  with  Submarine  trainer,  and  ANZACs  OBTS  (Stirling) 

Phase  4:  Establish  interoperability  with  other  ADF  systems  (2004+?) 

Phase  5:  Establish  interoperability  with  ships  at  sea  (2010?) 

There  is  potential  to  extend  this  environment  to  include  ships  at  sea,  although  this 
requirement  will  create  various  communication  challenges.  Further  in  the  future  a 
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DIS/HLA  capability  will  enable  the  RAN  to  participate  in  international  simulated 
exercises. 

SEA  1412  will  initially  use  the  IEEE  standard  Distributed  Interactive  Simulation  (DIS) 
protocols  to  link  the  systems  but  is  expected  to  migrate  to  the  newer  High  Level 
Architecture  as  this  technology  matures.  A  key  requirement  in  migration  to  HLA  is  the 
development  of  a  suitable  Federation  Object  Model  (FOM)  which  describes  the  data 
structures  for  maritime  warfare.  This  may  be  based  on  the  USN  Navy  Meta  FOM 
currently  under  development  by  the  USN  Battle  Force  Tactical  Training  (BFTT)  Project. 
Other  technical  challenges  entail  the  distribution  of  data  link  and  voice 
communications  across  both  LANs  and  WANs. 

DSTO,  through  AOD  and  MOD  tasking,  has  supported  development  of  this  Project 
during  the  last  6  years,  through  Concept  Development,  Feasibility  Study,  Proposal 
Evaluation,  Tender  Evaluation,  and  Contract  Negotiation.  Government  approval  has 
been  granted  for  Phase  2  of  SEA  1412  that  entails  linking  the  DDG/FFG  trainer  with 
the  ANZAC  trainer  at  HMAS  Watson  in  Sydney. 

Project  Arrangement  10 

Project  Arrangement  (PA10)  is  a  research  agreement  negotiated  between  Australia  and 
the  United  States  to  conduct  collaborative  Research  and  Development  in  aircraft 
Electronic  Warfare  Self  Protection  (EWSP)  systems.  Activities  to  be  conducted  under 
PA10  include  technology  and  technique  development,  modelling  and  simulation, 
laboratory  demonstrations  of  integration  concepts,  and  some  field  demonstrations.  The 
Australian  activities  are  being  conducted  under  Project  AIR  5406  -  Phase  I  and  Phase  II. 
PA10  consists  of  ten  research  and  development  tasks  scheduled  to  occur  over  a  six  year 
period  (begun  in  1998),  and  was  designed  as  a  vehicle  to  meet  a  requirement  identified 
by  the  ADF  to  develop  and  validate  EWSP  techniques  and  assess  EWSP  technology  in 
support  of  EW  acquisition  programs.  The  assessment  of  EWSP  technology  is  done  to  a 
large  extent  via  the  use  of  modelling  and  simulation.  In  the  context  of  Electronic 
Warfare,  modelling  and  simulation  can  allow  the  evaluation  under  realistic  conditions 
of  the  performance  both  of  novel  EW  equipment  and  countermeasures  techniques  and 
also  of  the  EW  operators.  Task  5  of  PA10  aims  to  develop  a  capability  to  conduct 
human-in-the-loop  simulation  trials  which  include  high-fidelity  models  of  EWSP 
equipment.  To  date  HiL  simulations  incorporating  constructive  simulation  elements 
have  been  conducted  by  linking  sites  at  DSTO  Melbourne,  DSTO  Salisbury  and 
CECOM  (US  Army)  at  Fort  Monmouth,  New  Jersey,  USA. 


13 


DSTO-GD-0270 


3.  Simulation  Architecture 

3.1  Operational  Architecture 

Operating  Concept 

The  following  figure  illustrates  an  operating  concept  for  the  Defence  distributed  Joint 
Synthetic  Environment  (JSE).  In  order  to  understand  the  requirements  of  the 
distributed  simulation  system,  the  full  scope  of  its  functionality  and  types  of 
interaction  in  its  environment  are  required.  The  whole  environment  is  driven  by  plans 
derived  from  purposeful  questions,  experiments,  training  needs,  tests,  or  other 
requirements.  The  Planners  develop  scenarios,  vignettes,  specify  questions  to  be 
addressed  and  define  measures  to  be  instrumented.  Two  other  key  domains  are  shown, 
the  Military  Environment  and  Models  &  Simulations5.  The  Military  Environment  may 
have  Real  Operations  in  addition  to  Participants  and  Users  in/ of  the  M&S  capability. 
Participants  and  Users  utilise  a  range  of  systems,  including  their  operational  systems, 
and  direct  interfaces  to  the  Models  and  Simulations.  The  overall  capability  also 
includes  Assemblers,  who  compose  a  total  simulation  solution  from  component 
models  and  simulations  available  in  repositories.  Response  Cells  &  Operators  are 
needed  to  bridge  the  gap  (media,  fidelity,  ...)  between  Participants  &  Users  (eg 
Response  Cells  in  ADF  simulation-based  CPX  and  wargaming),  to  represent  higher 
control  and  flank  agencies  and  to  enhance  the  behaviour  of  simulated  entities  and 
systems  (eg  as  in  semi-automated  forces).  Controllers  shape  the  overall  environment 
through  injection  of  stimuli  and  directives:  eg  keeping  an  exercise  on  track,  and 
making  sure  key  issues  are  covered.  An  Audience  of  Analysts,  Umpires,  Scrutineers  etc 
observe  the  conduct  of  the  activity.  All  people  outside  of  the  M&S  box  are  real  people. 


5  Note  that  a  'synthetic  environment'  embraces  the  Models  &  Simulation,  Intermediaries  &  Operators  and 
the  various  two-way  interfaces  with  the  Military  Environment.  Both  the  Military  Environment  and  Models  & 
Simulations  may  be  distributed.  The  concept  also  works  for  augmented  reality  configurations. 
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External  Drivers  and  Info 


Figure  4:  Operating  Concept  for  Simulation  Services  on  EXC3ITE 

Interactions  can  occur  within  the  Military  Environment.  Real  operations  may  feed  data 
to  Participants  &  Users  and  shape  the  simulation  world  as  an  "external  input". 
However,  any  information  flow  or  movement  of  code  from  Participants,  or  Models  and 
Simulations  (which  includes  data  repositories)  should  be  barred  or  carefully  managed. 

Elements  of  this  most  general  case  disappear  or  meld  with  others  depending  on  the 
specific  configuration  and  purpose.  Consider  the  following  examples: 

•  Training  a  HQ 

-  All  elements  are  largely  active 

-  A  notional  opposing  force  (OPFOR)  may  be  supported  by  Operators  or  may  be 
Participants  also  if  this  is  a  training  requirement  (eg  in  the  case  of  Exercise 
PitchBlack) 

•  Employing  simulations  for  Planning  purposes  (eg  using  simple  logistic  modelling) 

-  Real  Ops  raise  a  requirement  to  look  at  certain  issues. 

-  EXC3ITE  has  delivered  the  capability  for  military  Users  to  be  Assemblers  of 
appropriate  models  and  simulations 

-  No  Intermediaries  and  Operators  needed 
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-  No  Controllers  or  Audience 

-  Maybe  need  to  take  feeds  from  real  systems  as  External  Input 

-  Model  results  inform  Real  Ops 

This  framework  for  simulation  is  in  common  with  that  devised  to  allow  separation  of 
roles  in  efficiently  creating  new  applications  under  the  Java  2  platform  Enterprise 
Edition  (J2EE™)  model.  A  J2EE  application  (like  a  simulation)  consists  of  a  number  of 
components  that  maybe  derived  from  separate  sources.  J2EE  specifies  three  roles,  each 
performing  a  stage  in  making  an  application  available  for  use.  These  stages  aim  to 
separate  different  skill  sets,  and  different  functions  within  an  organisation,  from  R&D 
application  knowledge,  to  administration.  The  roles  are: 

1.  The  Creator  develops  a  component,  by  providing  an  implementation  of  a 
defined  interface.  S/he  has  knowledge  of  the  business  logic  of  that 
component,  but  need  have  no  knowledge  of  middleware. 

2.  The  Assembler  takes  components,  created  from  various  sources,  and 
gathers  them  into  an  application. 

3.  The  Deplayer  installs  the  application  on  a  J2EE  platform,  and  configures 
and  integrates  it  into  the  existing  infrastructure.  This  person  is  concerned 
with  middleware,  and  is  the  only  one  who  is  concerned  with  the 
application  transport  mechanism  -  CORBA  vs  RMI,  etc.  Most  decisions 
about  naming,  security  and  transactions  can  be  postponed  to  this  stage, 
removing  the  need  for  developers  in  the  earlier  roles  to  consider  them. 

This  split-up  of  roles,  and  compartmenting  of  knowledge  it  implies,  works  because  of 
the  precise  specification  of  the  materials  passed  between  stages. 


J2EE  Model 


i 


Deployer 


Figure  5:  Java  enterprise  model  indicating  hierarchy  of  roles  in  development  of  components 
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3.2  Systems  Architecture 

3.2.1  EXC3ITE  Services 

This  section  discusses  the  classes  (or  categories)  of  service  that  are  provided  by 
EXC3ITE,  to  prepare  for  the  following  section  that  describes  simulation  requirements 
as  specialisations  of  these  classes  or  instances  of  the  classes. 

The  systems  architecture  of  EXC3ITE  is  founded  on  the  concept  of  the  use  of 
components  to  encapsulate  intellectual  capital,  at  a  level  of  granularity  that  allows 
sharing  and  re-use  to  construct  C3I  applications  rapidly  and,  where  possible,  under  as 
much  control  of  the  user  as  possible.  Whilst  the  level  of  granularity  is  an  ongoing 
research  topic,  the  breakdown  presented  in  this  section  serves  to  guide  the  construction 
of  components  at  this  time  and  continue  to  guide  thinking  for  the  life  of  the  current 
phase  of  EXC3ITE. 

EXC3ITE  always  assumes  the  underlying  foundation  of  middleware  to  provide  a 
guaranteed  quality  of  service6  while  hiding  details  of  underlying  communications 
network  and  the  extent  of  geographical  separation  of  EXC3ITE  participants.  Services 
(provided  as  components)  are  expected  to  nm  as  location-independent  entities  within  a 
distributed  system  with  the  potential  to  be  executed  remotely  to  provide  a  service, 
and/or  fetched  from  a  repository  and  started  up  on  a  convenient  machine  on  the  fly. 

Components  in  EXC3ITE  are  described  architecturally,  which  means  that  function  and 
interface  describe  them7.  Some  classes  of  component  form  a  natural  hierarchy,  but 
components  are  generally  designed  to  allow  applications  to  be  formed  from  a  network 
of  peers.  For  example,  applications  are  likely  to  be  formed  from  a  number  of 
components  from  the  "Value-Add"  class  with  no  natural  hierarchy. 

Some  classes  described  below  have  instances  that  support  different  technologies  and 
are  interoperable  only  through  bridges.  The  EXC3ITE  Engineering  Management  Plan8, 
which  sets  out  the  guidelines  for  structure  and  services  on  EXC3ITE,  intentionally  does 
not  specify  a  particular  kind  of  middleware.  Instead  it  states  the  intention  to  support 
multiple  technologies,  which  include  CORBA,  DCOM  and  J2EE  as  recognised  priorities 
for  support  in  the  immediate  future. 


6  Quality  of  Service  will  be  more  important  to  simulation  users  of  EXC3ITE  who  will  need  to  drive 
development  of  this  aspect  of  core  services,  currently  seminal. 

'  IEEE  Standard  Glossary  of  Software  Engineering  Terminology,  IEEE  Std  610.12  1990,  states:  ‘The 
structure  and  relationships  of  components  of  a  system  and  the  rules  guide  their  development  and 
evolution” 

8  EXC3ITE  Engineering  Management  Plan,  Report  DSTO-TR-1002,  AR  001-503,  and  available  online  at 
www.exc3ite.dsto.defence.aov.au 
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EXC3ITE  Technical  Reference  Guide9  contains  details  of  the  EXC3ITE  architecture  and 

currently  available  services.  This  description  is  frozen  at  the  time  of  publication  of  this 

(ESS)  document. 

Classes  of  service 

Data  Repository  class 

This  is  the  most  basic  class  and  refers  to  "databases"  with  common  interfaces,  or 
databases  paired  with  appropriate  data  adapters  to  allow  them  to  join  EXC3ITE 
federations.  Most  legacy  databases  with  paired  adapters  (known  as  wrapped 
databases)  fall  in  this  class.  Existing  examples  of  this  class  are  the  IMAD  libraries, 
the  geospatial  SDE  server.  Future  examples  include  legacy  databases  paired  with 
MANIFOLD  wrappers. 

Data  biter  change  Class 

This  class  contains  data  adapters  which  take  raw  feeds  of  data  and  transform 
them  into  data  objects  that  are  available  to  other  EXC3ITE  components.  Existing 
examples  of  this  class  are  the  data  feeds  derived  from  message  traffic,  supplying 
track  data  as  events.  EXC3ITE  has  a  generic  data  feed  adapter  that  makes 
creation  of  a  new  member  of  this  class  straightforward.  EXC3ITE  has  under 
construction  a  "publish  and  subscribe"  mechanism,  which  will  fall  into  this  class. 

Data  Federation  Class 

Data  federation  is  an  important  philosophical  approach  to  providing  EXC3ITE 
applications  with  location  and  format  independent  access  to  data.  The  main  idea 
is  that  a  federation  service  mediates  in  all  database  access  in  order  to 
automatically  find  the  database  and  arrange  retrieval  by  the  most  appropriate 
means.  There  is  also  a  requirement  for  the  federator  to  provide  or  facilitate  data 
format  conversion.  Examples  of  this  class  are  the  IMAD  federator  and  the  CDEIS 
service.  It  is  intended  that  this  class  will  eventually  include  agents  to  track  usage 
of  data  and  relocate  it  to  the  most  appropriate  location  to  improve  quality  of 
service,  but  this  remains  a  research  goal  at  present. 

Core  Service  Class 

This  class  contains  component  that  expose  important  functions  of  the  EXC3ITE 
infrastructure,  especially  those  provided  by  middleware.  This  class  contains 
Operating  Systems  Services,  Distributed  Computing  Services,  Network  Services 
and  Security  Services.  Current  examples  of  this  class  are  the  trader,  directory  and 
naming  services  (for  location  of  active  services  on  the  system),  security  services 
(to  provide  authentication),  the  transmission  availability  forecaster  (a  seminal 
service  to  provide  Quality  of  Service),  and  the  starlight  data  diode.  This  class 
includes  inter-technology  bridges  (currently  CORBA-DCOM  supported  in  the 
prototype  environment).  This  class  potentially  includes  tools  for  collaboration 
and  tools  to  assist  construction  of  robust  applications. 

9  EXC3ITE  Technical  Reference  Guide,  www.exc3ite.dsto.defence.aov.au.  an  online  evolving  document. 
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C3I  Value-add  Class 

This  class  contains  many  C3I  domain  specific  functions.  It  is  expected  that 
applications  will  consist  of  a  large  number  of  calls  to  these  services  and  recursive 
use  of  some  of  these  services  is  possible.  This  class  potentially  contains  any 
legacy  functionality  required  by  EXC3ITE  assemblers  through  wrapped 
applications.  Existing  diverse  examples  of  this  class  include  the  track  services, 
DICE  services  and  TBS  access  service.  Intervisibility10  services,  fusion  services 
and  3D  visualisations  services,  all  potentially  fit  into  this  class. 

User  Interface  Class 

The  EXC3ITE  component  philosophy  extends  to  considering  user  interfaces  to  be 
provided  by  service  components,  which  should  enable  re-use.  Examples  of  this 
class  are  COTS  browsers  such  as  Netscape  and  Explorer,  and  adaptations  of 
COTS  products  such  as  Battlescape/EDGE. 

Business  Process  Class 

This  class  contains  the  components  that  are  least  likely  to  be  re-used.  A  business 
process  component  corresponds  to  an  "application"  in  that  it  includes  the 
business  logic,  the  glue  for  cementing  together  collections  of  other  components, 
and  particularly  the  scripting  necessary  to  control  the  user  interface.  An  example 
of  this  class  is  the  proposed  eBrief  service. 

Component  Repository  Class 

This  class  provides  a  service  to  developers,  and  is  analogous  to  a  database 
containing  components  rather  than  data  entities.  A  component  repository  is  store 
of  components,  which  makes  itself  available  for  resource  discovery  by 
conforming  to  a  resource  discovery  protocol.  Examples  of  component  repository 
types  are  a  JINI  repository,  a  RACE  component  repository,  and  CORBA 
component  repository.  EXC3ITE  seeks  to  limit  the  number  of  types  of  repository 
in  order  to  make  components  sharable  to  the  largest  number  of  users  possible. 
However,  currently  there  is  no  formal  limitation,  and  simulation  users  may  wish 
to  create  a  simulation  specific  type  of  repository. 

Instrumentation  Class 

This  class  was  intended  to  provide  housekeeping  functions  for  the  EXC3ITE 
infrastructure  management,  but  has  the  potential  to  be  extended  to  support 
simulation. 


10  Intervisibility  determines  the  existence  of  an  unoccluded  line-of-sight  between  two  points  in  3 
dimensional  space. 
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3.2.2  Simulation-Specific  Services 

It  is  proposed  that  in  order  to  support  simulation,  that  EXC3ITE  support  instances  of 
these  classes  which  are  delineated  as  "simulated"  as  opposed  to  "real".  The  most 
straightforward  manifestation  would  be  "simulation"  data  repositories,  but  also 
envisaged  are  repositories  of  "simulation"  components. 

Jon  Vaughan  and  Mike  Davies11  identified  four  principal  categories  of  service  to 
support  simulation,  namely: 

1.  Repositories  of  simulation-related  material  which  might  include:  terrain  datasets  (for 
virtual  and  constructive  systems);  SEDRIS  tools;  visual/IR  models  of  entities; 
executable  e.g.  flight  models;  command  agents;  tools  for  calculating  line-of-sight 
range  and  optimum  routing;  latency  and  packet-analysers;  datasets,  for  example, 
platform  characteristics;  various  information  and  reference  sources;  lessons  learnt 
etc. 

2.  Stimulation  services  to  be  used  to  feed  or  stimulate  a  simulation  with  recorded 
data.  The  data  origin  might  be  live  (tracks,  weather,  atmospheric /oceanic 
propagation  conditions,  sea-state  etc.)  or  simulated  (from  prior  experiments  or 
purpose-generated)  with  the  capability  to  manipulate  the  data  time  base  and 
stimulate  at  rates  appropriate  to  the  purpose. 

3.  Immersive  synthetic  environments  constituting  interactive  systems  of  systems, 
potentially  including  human-in-the-loop,  at  fidelities  which  support  appropriate 
interaction  with  the  system  under  test,  training  or  study. 

4.  Translation  services  which  might  include  coordinate  converters;  DIS  to/from 
HLA;  tracks  to/from  HLA;  suitably  broad-based  or  simulation-service- 
recommended  FOMs;  RTI  Interface  Definition  (RID)  files  etc. 

These  categories  map  relatively  simply  to  the  EXC3ITE  classes.  Category  one  maps  to 
the  component  repository  and  data  repository  classes  described  above.  Tools  described 
under  this  category  will  be  stored  in  component  repositories,  but  fall  into  a  number  of 
classes  such  as  C3I  value  add  and  instrumentation  classes. 

Stimulation  services  will  be  simulation-specific  instances  of  various  EXC3ITE  classes, 
and  'immersive  synthetic  environments'  will  be  a  simulation-specific  instance  of  a 
Business  Process  class.  Examples  of  translation  category  map  less  cleanly  into  data 
interchange  class  and  business  process  classes. 

Comparison  of  the  six  use  cases  supplied  in  the  appendices  reveals  a  high  degree  of 
overlapping  requirements  and  similarity  in  structure  and  function.  In  terms  of  the 


11  Vaughan,  J  &  M.  Davies  -  EXC3ITE  Simulation  Service:  bringing  simulation  into  the  operational  domain, 
SimTecT-2000  (28  February  -  2  March  2000)  Conference  Proceedings,  pp  39-44. 
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EXC3ITE  classes  of  service  these  requirements  can  be  satisfied  by  services  as  follows 
(categorised  as  instances  of  the  classes): 

Data  Repository  class 

Live  feeds  from  real  assets:  JORN  and  others. 

Stimulation  of  real  systems  by  simulated  data:  BCSS,  Phoenix 

Terrain  and  environmental  services:  Australian  and  regional  terrain  data  sets 

including  elevations,  imagery,  cultural  features,  and  vegetation  data. 

Data  services  which  acknowledge  the  requirement  for  timeliness  of  derived 
data:  Trafficability,  mobility.  (With  an  ideal  infrastructure,  these  could  be 
generated  as  required  from  primary  data.) 

Data  Interchange  Class 

There  will  need  to  be  translators  of  different  kinds  to  support  the  use  cases,  but 
these  are  implicit,  but  common  requirements  have  not  yet  been  explicitly 
developed..  Examples  are  DIS/HLA  translator. 

Data  Federation  Class 

SEDRIS  services  (SEDRIS  supports  simulation  data  for  terrain  and  environment  in 
particular,  but  is  applicable  to  a  much  wider  set  of  data  types) 

Core  Service  Class 

The  requirement  for  core  services  in  implicit  in  the  Use  cases. 

C3I  Value-add  Class 

Components  to  derive  geospatial  data  such  as  mobility  and  trafficability. 

DICE 

User  Interface  Class 

Stealth  viewers 
Battlemap  displays 

Business  Process  Class 

Immersive  Synthetic  Environment  Services:  Distributed  collaborative 

environments 

Component  Repository  Class 

Visual  models  of  platforms: 

Surface  ships  such  as  FFG,  hostile  vessels 

Helicopters  such  as  BlackHawks,  Chinooks,  ARHs,  naval  helos 

Fixed  wing  aircraft  such  as  F/A18,  C130,  commercial  aircraft,  hostile  air 

Tactical  UAVs 

Vehicles  such  as  ASLAV,  APC,  4WDs 

Ground  elements  such  as  Bde  HQ,  GBAD,  grd  based  fire  support  (artillery) 
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Behavioural  models: 

Dynamics  for  constructive  renditions  of  above  platforms  (currently  these 
are  supplied  in  such  simulation  environments  as  ModSAF,  JANUS  (and 
BattleModel?)  -  but  the  aim  would  be  to  have  a  library  of  composable 
models  to  draw  from) 

(Dynamics  for  H-I-L  renditions  of  above  platforms  are  more  hardware 
specific  since  they  must  be  tightly  integrated  to  the  human  interfaces,  so 
they  would  tend  to  reside  in  HIL  facilities  such  as  AOSC  and  SERF  -  there 
is  not  currently  a  strong  requirement  for  an  EXC3ITE  service  of  them) 
Sensor  models  -  these  would  span  a  range  of  fidelities,  broadly  classed  in  two 
categories: 

Those  producing  detection  reports  only,  and 

Those  producing  simulated  sensor  data  for  feeding  to  human  observers 
and/or  data  processing  and  fusion  applications. 

The  sensors  required  include  IRST,  ESM,  Microwave  radar.  Fire  control 
radar,  GBAD  radars,  JORN,  Visual,  Image  Intensified  (night  vision  goggles) 
C2  models: 

such  as  command  agents,  Petri  nets  .  .  much  of  the  common  use  case 
requirement  could  currently  be  met  by  DICE  (with  suitable  modifications) 
-  it  is  mostly  routing  of  information  and  commands.  More  sophisticated 
agents  capable  of  interpreting  and  acting  on  information  and  commands 
are  under  development  and  could  be  freestanding  or  incorporated  in  DICE 
too  -  this  needs  further  consideration. 

Communications  models 

A  common  requirement  is  for  a  comms  server  to  ensure  that  any  message, 
voice  or  data  link  between  any  two  nodes  on  the  battlefield  is  mediated 
with  the  appropriate  availability,  bandwidth,  delay,  degradation  and  so  on. 
This  requirement  has  already  been  scoped  in  some  detail  by  Marcel  Scholz 
et  al  in  Comms  Div  and  should  be  a  high  priority  for  development  as  an 
EXC3ITE  simulation  service. 

Weapons  models: 

including  ROE  and  generating  appropriate  data  for  targets  to  compute 
their  own  damage  by  Artillery 
ASM  and  Anti- ASM  Missiles 
GBAD 

Other  platform  weapons  (Hellfire,  rockets  etc) 

Other  'behaviours'  such  as  target  marking  (eg  phosphorus)  and  designating 
(laser)  -  it  is  not  clear  yet  whether  these  should  be  treated  as  a  potential 
service  or  remain  domain  specific. 

Environmental  effects  server  for  sensor  models  -  requirement  has  not  been 
articulated  yet  but  is  likely  to  emerge  soon. 

Instrumentation  Class 

The  goals  of  instrumentation  may  be  split  into  two  categories,  as  follows: 
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1.  Warfigh ting  Analysis 

a.  Process  measures  (ie  what  services  used /not  used,  timeliness  of 
responses  etc) 

b.  Outcome  measures  (kills,  missiles  fired,  misses,  fuel  consumed  etc) 

2.  Simulation  System  Performance 

a.  Performance  measures  (latency,  bottlenecks,  loading  etc) 

b.  Diagnostics  (assist  diagnosis  of  problems  in  eg.  Latency,  loading  etc) 

A  useful  way  of  characterising  instrumentation  is  using  a  3-layer  model  as 
follows: 

User  Queries  /  Reports.  This  level  represents  the  goals  of  instrumentation  -  what 
questions  are  being  asked,  for  which  instrumentation  data  and  analysis  is 
required.  The  requirements  could  range  from  being  able  to  replay  a  given 
scenario  or  experiment,  to  a  simple  measure  of  blue/red  kills. 

Analysis  Services.  This  level  specifies  general  and  specific  analysis  facilities 
required,  based  on  an  understanding  of  the  likely  questions  to  be  asked,  and 
available  data.  Services  may  range  from  relatively  simple  statistical  packages  to 
more  complex  visualisation  of  the  filtered  data. 

Data.  This  level  represents  the  raw  and/or  pre-processed  data,  which  is 
recorded  by  the  system  or  sub-systems.  Some  automatic  pre-processing  of  data 
may  be  required  to  get  the  data  into  a  form  where  it  can  more  readily  be 
analysed.  Some  of  this  data  may  be  recorded  passively  from  simulated  sensors 
and  services,  while  other  data  might  be  actively  requested,  depending  on  the 
analysis  goals. 

This  class  is  to  include  simulation  specific  tools  to: 

■  compute  and  display  realtime  metrics  such  as  performance  measures 
relevant  to  Situation  Awareness  (quality,  timeliness,  availability  of  relevant 
info) 

■  capture  SA  metrics  from  relevant  players  (such  as  AAR  tools,  interrogators, 
etc  -  this  has  yet  to  be  defined  and  developed  but  is  a  common 
requirement) 

■  capture  and  display  force  effectiveness  metrics  and  lower  order  MoPs  such 
as  real-time  vulnerability  measures,  (detectability,  identifiability, 
targetability)  etc. 

3.2.3  Front-End  Issues  /  Interfaces 

The  front-end  or  application-to-simulation  interface  must  provide  the  user's  window 
into  these  kinds  of  services.  Even  though  some  requirements  are  quite  simple  (a 
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translator,  for  example,  might  only  need  a  Javascript  calculator  or  Java  applet),  if  a 
single  interface  concept  is  to  provide  entry  into  all  simulation  services  then  its 
capabilities  must  meet  the  needs  of  the  most  complex  'service'. 

One  way  to  proceed  is  to  think  in  terms  of  providing  four  different  kinds  of  portal  into 
these  services,  categorised  in  terms  of  increasing  levels  of  service  integration,  i.e., 

■  Type  1  -  does  not  provide  entry  into  the  service,  it  simply  describes  the  service.  It  is 
an  information  or  documentation  source,  most  likely  a  text  web  site  with  links  to 
related  sources.  For  some  services,  this  is  all  that  is  required,  or  all  that  is  feasible  to 
provide. 

■  Type  2  -  again,  does  not  provide  a  window  into  or  control  of  the  service.  It 
provides  a  comprehensive  help  system  for  using  the  service.  It  would  provide  links 
to  required  resources  and  assistance  in  their  use.  It  might  provide  a  troubleshooting 
facility  and  email  contacts  to  people  who  can  resolve  problems.  Options  for 
launching  smart  (wizard-type)  assistants  might  also  be  present. 

■  Type  3  -  can  be  described  as  a  'thin  client'.  Functionality  is  delivered  by  calls  from 
the  interface  to  the  underlying  distributed  services.  This  is  the  OpenMap 
philosophy  for  use  of  GeoSpatial  Services,  and  IMAD,  for  example.  Such  clients  can 
make  use  of  browser  plug-ins  to  increase  capabilities. 

■  Type  4  -  makes  no  calls  to  middleware,  it  provides  the  service  itself.  Through  an 
applet,  ActiveX  component  or  other  means,  it  provides  the  functionality  required. 
For  example,  a  relatively  simple  component  might  provide  line-of-sight  assessment 
on  a  terrain  database,  or  search  and  graphical  manipulation  capabilities  on  various 
simulation-related  databases. 

In  most  cases  it  would  be  preferable  to  provide  more  than  one  of  these  types  in  support 
of  a  service  so  that,  in  addition  to  providing  entry,  there  would  also  be  comprehensive 
documentation  and  guiding  and  supporting  (e.g.  troubleshooting)  systems. 

Under  current  EXC3ITE  way  of  doing  business,  documentation  in  support  of  types  1 
and  2  is  kept  on  line  on  the  EXC3ITE  web  site,  which  acts  as  a  primitive  portal.  Such 
documentation  is  a  condition  of  a  service  being  placed  in  the  demonstration 
environment.  There  is  currently  no  differentiation  between  type  3  and  type  4 
components,  although  the  potential  route  is  to  make  the  stores  of  these  components 
different  instances  of  component  repositories.  This  requirement  is  not  unique  to 
simulation  and  will  need  to  be  addressed  as  part  of  the  evolution  of  EXC3ITE. 

The  preferred  paradigm  for  the  front-end  is  an  area  that  needs  significant  research.  In 
simplistic  terms  it  might  look  like  a  choice  between,  on  the  one-hand,  the  familiar  web 
browser  type  interface  and,  on  the  other,  a  dedicated  (preferably  platform- 
independent,  ie.  Java)  application.  The  browser  model  has  much  to  commend  it.  It  is 
stable,  well  tried,  well  imderstood,  accepted  technology  with  almost  zero  training 
overhead.  Adopting  the  browser  model  would  allow  us  to  leverage  off  the  enormous 
international  development  efforts  continually  underway.  Applications  that  have 
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browser  interfaces  can  be  exposed  to  real  military  users  of  EXC3ITE  via  the 
EXC3ITE/JCSS  bridge.  Browser  technology  is  also  evolvable  which  would  not  be  the 
case  for  a  Java  application.  Mike  Sweeney12  advocates  standardising  on  the  browser 
model  (the  Browser  User-Interface  Service,  BUS)  as  a  common  interface  into  many  of 
the  existing  EXC3ITE  services. 

This  model  has  one  significant  limitation,  however.  It  can  display  service  outputs 
(which  may  be  quite  complex,  eg.  3D  objects,  or  streaming  video)  but  it  relies  on 
functionality  which  is  provided  by  the  underlying  service.  The  BUS  sends  the 
appropriate  messages  to  the  service,  then  receives  and  displays  its  outputs.  Since  the 
EXC3ITE  philosophy  precludes  provision  of  COTS  applications,  most  services  on 
EXC3ITE  are  and  will  be  written  specifically  for  its  environments.  Service 
functionalities  can  therefore  be  tailored  to  interact  through  a  browser  front-end  as  an 
initial  design  requirement,  so  serving  through  a  browser  interface  presents  no  problem. 

To  some  extent  the  same  might  be  said  of  simulation  services  for  EXC3ITE.  Though 
there  are  many  services  that  were  developed  elsewhere  and  will  not  be  re-written  or  re¬ 
worked,  many  fall  into  the  repository  and  translator  categories.  Systems  within  these 
categories,  e.g.  flight  models,  SEDRIS  tools,  packet  analysers,  coordinate  converters 
etc.,  can  simply  be  provided  (downloaded)  to  the  user  to  use/launch  according  to  their 
needs. 

At  the  more  complex  end  of  the  spectrum  of  services  -  supporting  distributed 
immersive  synthetic  environments  -  if  the  interface  is  intended  to  provide  a  controlling, 
managing  facility  then  the  browser  paradigm  starts  to  break  down.  The  browser  cannot 
encapsulate  the  functionality  of  existing  systems,  like  wargames  or  HLA  federations, 
and  management  of  multi-functional  systems  becomes  an  entirely  different  issue.  This 
is  the  problem  that  LOD's  Distributed  Study  Environment  must  deal  with,  having  to 
manage  a  wide  range  of  COTS,  GOTS  and  legacy  systems  in  a  distributed 
environment.  The  interface  must  deal  with  management  on  many  levels,  including 
bandwidth  (so  that  less  important  processes  cannot  deny  bandwidth  to  critical 
processes),  efficient  use  of  distributed  processing  capability,  and  local  screen  real- 
estate,  amongst  others.  (Ideally  for  such  a  complex  system,  entry  to  the  functionalities 
should  be  driven  by  user-centric  principles  which  dictate  that  the  interface  be  built, 
tried  and  tested  first,  and  the  services  should  then  be  tailored  to  fit  user  demands.)  At 
this  stage  the  nature  of  an  appropriate  solution  is  not  clear  and  needs  considerable 
research.  It  might  help  to  combine  efforts  under  this  project  (simulation  services  for 
EXC3ITE)  and  the  Distributed  Study  Environment  to  resolve  some  of  the  issues. 


12  Sweeney,  M,  EXC3ITE  Browser  User- Interface  Service,  EXC3ITE  web  site,  DSTO  Intranet  URL: 
http://exc3ite/pubs/pub  frame.htm 


25 


DSTO-GD-0270 


3.2.4  Self- monitoring  for  corporate  knowledge  and  evaluation 

From  an  early  stage  in  development  it  is  important  to  build  in  self-monitoring 
capabilities  to  gain  feedback  on  the  use  of  (and  nature  of  use  of)  simulation  services. 
This  information  could  be  used  to  improve  the  services  themselves,  and  the  interface 
(front-end)  facilitating  their  use.  Capturing  such  things  as  common  access  pathways  (to 
reduce  the  effort  to  reach  or  activate  a  service  if  it  were  many  clicks  down),  should  be 
used  to  drive  user  interaction  efficiency.  There  should  also  be  potential  (and  requests) 
for  explicit  user  feedback.  Services  to  support  simulation-specific  requirements  would 
be  a  natural  extension  of  the  EXC3ITE  instrumentation  class. 

3.2.5  Collaboration 

Whilst  collaboration  services  have  been  flagged  as  an  important  part  of  EXC3ITE 
infrastructure,  at  this  time  no  instances  of  collaboration  services  exist.  Collaboration 
takes  on  special  significance  in  the  context  of  simulation.  Any  front-end  into  EXC3ITE 
services  may  wish  to  include  collaboration  tools£  for  example,  dropping  in  a  JavaBean 
to  launch  a  shared  whiteboard,  or  being  able  to  synchronise  track  views  across 
distributed  collaborators.  This  is  a  rich  area  for  research. 


3.3  Technical  Architecture 

This  section  relates  specifically  to  the  manner  in  which  the  interactive  stimulation  or 
synthetic  environment  services  may  interoperate  and  communicate  within  the  larger 
EXC3ITE  environment.  It  discusses  the  problems  of  distributed  simulation 
interoperability  from  the  perspective  of  the  ADF  and  EXC3ITE  and  seeks  to  identify  a 
way  forward  for  allowing  interconnection  of  separate  synthetic  environments  being 
developed  within  the  ADF  and  DSTO,  including  the  Land,  Air  and  Maritime 
environments  and  numerous  EXC3ITE  simulation  projects.  Appendix  H  provides  a 
background  on  the  Distributed  Interactive  Simulation  (DIS)  and  High  Level 
Architecture  (HLA)  standards. 

The  EXC3ITE  network  backbone  is  a  high-bandwidth  Asynchronous  Transfer  Mode 
(ATM)  network  operating  over  commercial  optical  fibre  and  using  military  grade 
encryption.  Applications  on  EXC3ITE  operate  using  TCP/IP  connectivity  which  is 
routed  over  the  ATM  network.  Network  nodes  are  assigned  as  different  TCP/IP 
subnets.  Satellite-connected  nodes  will  suffer  appreciable  (1-2  second)  round-trip 
latency  in  communicating  with  other  nodes,  due  to  the  distance  to  the  geostationary 
orbits.  They  will  also  have  less  bandwidth  available  than  the  land-connected  nodes.  It 
is  unclear  at  this  stage  how  the  increased  latency  and  reduced  bandwidth  would  effect 
the  efficiency  of  either  the  CORBA  or  DCOM  protocols.  If  significant  hand  shaking  is 
involved  between  nodes,  then  there  could  be  a  considerable  impact  of  performance  of 
time  critical  applications  such  as  real-time  interactive  simulation. 
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3.3.1  System  Performance  Challenges 
Quality  of  Service  (QoS) 

Network  latency  is  one  of  the  major  barriers  to  large-scale  simulations.  Resource 
reservation  and  multicasting  are  two  important  networking  capabilities  required  to 
support  distributed  simulations.  Resource  reservation  is  able  to  ensure  that  different 
levels  of  service  quality  are  established  across  the  network  supporting  distributed 
simulations.  With  resource  reservation,  users  are  able  to  reserve  a  specified  amount  of 
bandwidth  so  those  packets  may  be  delivered  with  the  required  QoS. 

Multicasting 

An  attempt  at  overcoming  bandwidth  limitations  has  focused  on  using  existing 
bandwidth  more  efficiently  and  reducing  the  amount  of  bandwidth  demanded  by 
distributed  simulations.  Multicasting  takes  advantage  of  the  efficiency  obtained  when 
the  network  can  recognise  and  replicate  information  packets  that  are  destined  to  a 
group  of  locations.  Under  these  circumstances,  the  network  can  take  on  the  job  of 
providing  duplicate  copies  to  all  destinations,  thereby  greatly  reducing  the  amount  of 
information  flowing  into  and  through  the  network. 

While  the  HLA  does  not  specify  use  of  a  multicasting  network,  it  has  similar 
requirements  for  many-to-many  transmission  of  object  attributes  at  rates  in  excess  of 
one  update  per  object  per  second  that  cannot  be  met  without  multicasting.  The 
network  supporting  distributed  simulations  will  necessarily  be  able  to  support 
multicasting  for  various  simulated  exercises,  ranging  from  tens  to  hundreds  of 
simulation  objects  distributed  across  a  number  of  sites.  As  the  number  of  distributed 
objects  increases,  building  multicasting  networks  potentially  supporting  thousands  of 
simultaneous  multicast  groups  with  large  group  change  rates  is  a  difficult  problem. 

There  is  a  need  to  develop  multicast  protocols  that  can  provide  the  quality  of  service 
needed  for  distributed  simulation,  where  different  types  of  messages  must  be 
transmitted  with  different  degrees  of  reliability  and  latency.  In  the  HLA  environment, 
we  can  identify  a  number  of  transmission  requirements13: 

1.  low-latency  reliable  packet  delivery,  for  exchange  of  occasional  data  among 
arbitrary  members  of  multicast  groups; 

2.  reliable  point-to-point  transmission  of  control  information  between  individual  RTI 
components; 


13M.  Pullen,  M.  Myjak,  and  C.  Bouwens,  “Limitations  of  Internet  Protocol  Suite  for  Distributed  Simulation  in 
the  Large  Multicast  Environment,”  RFC  2502,  IETF,  February  1999. 
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3.  best-effort  low-latency  multicast  of  object  attributes  that  often  change  continuously, 
eg.,  position  of  mobile  objects; 

4.  reliable  but  not  necessarily  real-time  multicast  distribution  of  supporting  bulk  data 
such  as  terrain  databases  and  object  enumerations;  and 

5.  low-latency  reliable  multicast  of  object  attributes  that  do  not  change  continuously 
but  may  change  at  arbitrary  times  during  the  simulation,  eg.,  object  appearance. 

Area  of  Interest  Management 

At  a  higher  level  of  software  architecture,  incorporating  area-of-interest  managers 
(AOIMs)  in  multicast  routing  systems  can  direct  packets  of  information  across  a 
network  to  particular  groups  of  receivers.  The  AOIM  is  simply  a  layer  of  software  that 
assigns  state  changes  and  entity  interactions  to  particular  multicast  groups  instead  of 
being  broadcast  to  everyone.  Such  systems  allow  any  member  of  a  group  to  transmit 
messages  (containing  text,  voice,  video,  and  imagery)  to  all  other  members  of  the 
group  via  a  single  transmission.  Used  in  conjunction  with  multicast  routing,  AOIMs 
can  help  minimise  the  amount  of  bandwidth  needed  to  support  distributed 
simulations. 

This  approach  prevents  the  sender  from  having  to  transmit  individual  copies  of  the 
message  to  all  intended  recipients,  freeing  resources  for  other  purposes.  AOIMs  can 
distribute  partitioning  algorithms  among  hosts  rather  than  rely  on  a  central  AOIM 
server.  Partitioning  schemes  can  be  based  on  spatial  (geographic  groupings  based  on 
locality),  temporal  (eg.,  real-time  versus  non-real-time),  and  functional  (eg.,  voice 
communications,  aircraft)  characteristics.  Research  is  needed  to  help  define  a  network 
software  architecture  that  can  properly  use  AOIMs. 

In  summary,  simulation  services  require  message  exchange  with  different  degrees  of 
reliability  and  latency.  Due  to  the  need  for  real-time  multicast  protocols  with 
established  quality  of  service,  EXC3ITE  should  provide  suitable  networking  facilities 
for  the  anticipated  large-scale  distributed  simulation. 

3.3.2  Use  of  DIS  over  EXC3ITE 

Because  DIS  is  a  protocol  based  standard,  rather  than  a  middleware  specified  standard, 
such  as  HLA,  it  does  not  conceptually  fit  well  into  the  EXC3ITE  model.  DIS 
applications  broadcast  PDUs  to  every  node  within  a  subnet  rather  than  follow  the 
application-service  provider  model  that  is  preferred  within  EXC3ITE. 

An  additional  problem  is  that  DIS,  by  default,  broadcasts  only  within  a  given  subnet. 
As  each  node  of  EXC3ITE  is  assigned  a  separate  subnet,  it  is  problematic  to  distribute 
simulations  between  nodes.  This  can  be  overcome  by: 

•  Setting  up  switches  to  re-broadcast  UDP  packets  on  specific  sockets  to  other 
subnets.  This  can  be  used  for  specific  cases,  but  is  not  a  scalable  solution  if  we  do 
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not  know  in  advance  which  nodes  need  to  broadcast  to  which  others.  Switch 
reprogramming  is  not  a  trivial  task  and  having  all  nodes  broadcast  to  all  others 
would  flood  the  network  with  traffic  and  be  very  inefficient. 

•  Setting  up  specific  multicast  groups  and  configuring  the  simulators  to  multicast  to 
these  groups.  Again  switch  reprogramming  is  necessary  to  forward  packets 
between  subnets.  The  solution  is  more  scaleable  provided  you  know  in  advance 
which  IP  addresses  constitute  the  multicast  group  and  can  set  this  up  in  advance. 
Adding  a  new  simulator  or  viewer  node  which  has  not  previously  been  designated 
though  would  not  be  possible  and  you  loose  one  of  the  major  aims  of  EXC3ITE,  to 
mix  and  match  applications  and  services. 

•  Having  dynamic  IP  forwarder  processes  on  the  network  which  can  bridge  across 
the  subnets  and  be  configured  on  the  fly.  The  mobile  IP  technology  may  provide 
such  a  solution.  It  is  unclear  what  the  impact  on  latency  and  bandwidth  would  be 
except  to  say  that  it  would  suffer  higher  latency  and  the  forwarding  nodes  would 
become  bottlenecks  to  performance  as  the  number  of  DIS  entities  increased. 

DIS  is  sufficiently  well  defined  to  allow  virtual  plug  and  play  within  the  environment, 
provided  the  subnet-bridging  problem  may  be  overcome.  Any  DIS  compliant 
application14  should  be  able  to  be  connected  to  the  network  and  immediately  be  able  to 
take  part  in  the  simulation. 

Management  of  multiple  DIS  exercises  operating  simultaneously  within  EXC3ITE  may 
be  a  problem  unless  manual  methods  are  adopted  to  assign  a  DIS  exercise  ID  (which  is 
unique  for  each  exercise). 

For  real-time,  interactive  simulation  involving  human-in- the-loop  models  (particularly 
fast  movers),  the  DIS  community  had  adopted  a  figure  of  100ms  as  the  maximum 
allowable  latency  between  any  simulations.  In  a  typical  fast  mover  simulation,  a 
latency  value  any  higher  would  result  in  the  human  not  being  able  to  respond  to  a 
stimulus  before  the  action  has  occurred.  For  example,  he  may  not  see  an  incoming 
missile  before  it  hits  him.  However  for  other  types  of  simulation  a  lower  latency  figure 
may  well  be  acceptable,  particularly  for  models  involving  slower  moving  entities  and 
where  there  is  no  human-in-the-loop. 

A  higher  latency  is  acceptable  for  applications  which  simply  wish  to  view  the  DIS 
exercise,  for  example  a  stealth  viewer  or  an  analytical  tool  collecting  data.  Because  DIS 
is  a  broadcast  protocol  over  UDP,  with  no  acknowledgment,  it  should  run  acceptably 
over  the  high  latency  satellite  links  on  EXC3ITE,  provided  that  no  human-in-the-loop 
interaction  is  required.  The  ideal  situation  would  be  to  have  the  constructive 
modelling  taking  place  within  the  low-latency  fibre  based  EXC3ITE  nodes  and  to  use 
the  satellite  node  for  exercise  viewing  and  analysis  (or  vice  versa).  Splitting  the 


14  This  of  course  assumes  the  same  version  of  the  DIS  standard.  There  are  also  issues  with  fair  play, 
consistency  of  modelling  and  consistent  terrain  databases.  However  these  issues  will  affect  all  distributed 
simulations  and  are  not  specific  to  DIS.  It  may  also  be  necessary  to  add  DIS  enumerations  for  local 
entities  and  weapons. 
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constructive  modelling  across  a  satellite  link  may  still  create  problems  if  the  entities  on 
one  side  are  required  to  react  quickly  to  interactions  generated  from  the  other  node. 
This  problem  would  not  be  unique  to  DIS,  but  would  also  occur  in  HLA. 

3.3.3  Use  of  HLA  on  EXC3ITE 

It  is  anticipated  that  large  growth  in  the  number  of  participants  will  engage 
simultaneously  in  distributed  simulations.  Such  an  increase  in  scale  in  a  distributed 
simulation  implies  an  increase  in  the  size  and  complexity  of  virtual  worlds.  The  growth 
in  the  number  of  participants/  combined  with  the  increased  amount  of  information  that 
must  be  exchanged  among  participants,  place  additional  demands  on  available 
bandwidth  and  computational  power.  Consequently,  distributed  simulation  is 
required  to  operate  over  a  shared  wide  area  network  in  a  scalable  manner.  In  that  case, 
even  if  the  number  of  hosts  varies  from  a  few  to  thousands,  they  should  be  able  to 
interchange  state  data  with  sufficient  reliability  and  timeliness  to  sustain  a  virtual, 
visual  environment  containing  large  numbers  of  moving  objects. 

Real-time  simulation  requires  high-performance  systems  and  low  communications 
latency.  Adding  more  layers  of  abstraction  and  protocol  for  achieving  interoperability 
simply  works  against  the  need  to  meet  the  latency  and  performance  requirements  of 
distributed  simulations.  Required  accuracy  both  of  latency  and  of  physical  simulation 
varies  with  the  intended  purpose  but  generally  must  be  at  least  sufficient  to  satisfy 
human  perception.  The  HLA  only  specifies  a  RTI  that  is  responsible  to  transmit  data 
reliably,  which  may  choose  to  do  so  by  various  means  including  redundant 
transmission  using  best  effort  protocols. 

At  a  conceptual  level,  HLA  maps  well  into  the  EXC3ITE  service  based  model,  with  the 
RTI  being  used  instead  of  the  CORBA  protocols  (in  fact  some  versions  of  the  RTI  were 
implemented  using  CORBA).  The  problems  of  mapping  across  IP  subnets  should  be 
less  of  an  issue,  provided  some  care  is  taken  in  configuring  the  RTI  setup.  For  efficient 
transfer  of  information  between  nodes,  HLA  relies  on  multicast  groupings  being 
established,  which  must  be  detailed  in  the  RID  files  used  by  the  RTI  for  configuration. 
Without  carefully  optimised  RID  file,  the  RTI  will  still  work,  although  a  lot  less 
efficiently  that  otherwise  with  appreciable  latency  and  bandwidth  overheads. 

Overall  current  implementations  of  the  RTI  are  benchmarked  to  be  almost  as  efficient 
as  DIS  for  small  scale  federations  (few  entities)  and  to  exceed  DIS  performance  when 
large  scale  federations  are  involved,  using  the  mapping  space  filtering  provided  in 
HLA.  However  little  information  is  available  on  the  use  of  HLA  over  a  high-latency 
satellite  links  and  it  is  unclear  whether  there  would  be  added  problems  with 
handshaking  across  the  link.  HLA  employs  two  modes  of  data  delivery,  best-effort 
(using  UDP  multicast  groups)  and  reliable  (using  TCP  point  to  point  transfers).  It 
could  be  expected  that  the  best-effort  traffic  would  not  suffer  any  penalty  over  DIS 
since  both  employ  UDP,  but  the  reliable  traffic  would  suffer  appreciable  lags,  due  to 
the  hand-shaking  required  in  the  TCP  protocol.  Federation  designers  would  need  to  be 
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aware  of  this  detail  and  take  it  into  account  when  designing  FOMs  which  specify  such 
information. 

Given  that  there  will  still  be  a  physical  latency  introduced  on  a  satellite  link,  the  same 
conditions  on  splitting  modelling  across  the  link  apply  as  for  DIS  -  where  possible, 
most  modelling  should  be  kept  to  one  side  of  the  link,  with  only  viewers  and  analysis 
tools  on  the  other  end.  As  mentioned  above  this  problem  may  be  particularly  acute 
when  reliable  message  passing  is  involved. 

Various  versions  of  the  RTI  exist  and  most  are  incompatible  with  each  other.  An 
application  compiled  for  a  particular  version  of  the  RTI  (irrespective  of  the  version  of 
the  HLA  standard  involved)  is  generally  not  able  to  communicate  with  another 
application  compiled  with  a  different  RTI.  Thus  within  the  EXC3ITE  environment,  it 
would  be  necessary  to  standardise  which  RTI  is  in  use.  It  would  also  be  necessary  to 
run  the  RTI  executive  processes  (required  by  most  RTI  implementations  to  keep  track 
of  the  federates  involved)  on  a  set  server  within  the  EXC3ITE  environment.  These 
processes  would  require  some  administration  as  they  need  to  be  present  all  of  the  time 
for  any  federation  to  be  able  to  operate  -  someone  must  make  sure  they  are  always 
running! 

HLA  does  allow  for  low-level  process  monitoring  through  the  built-in  Management 
Object  Model  (MOM)  classes  that  would  permit  the  EXC3ITE  network  researchers  to 
examine  packet  transfer  rates  and  latency. 

FOM  Interoperability 

One  of  the  biggest  drawbacks  of  HLA  is  the  fact  that  for  a  federate  to  join  a  federation, 
its  SOM  must  be  compatible  with  the  federation's  FOM.  This  means  that  off-the-shelf 
compatibility  with  HLA  is  unlikely,  which  contrasts  with  the  situation  in  DIS.  If 
federate  A  calls  a  ship  something  different  to  the  rest  of  the  federation  and  in  addition 
represents  its  location  using  a  different  representation,  then  there  is  no  simple  way  it 
can  join  the  exercise.  Federation  participants  must  manually  resolve  any  conflict 
between  object  models. 

To  overcome  this  problem,  the  US  DMSO  has  specified  a  number  of  reference  FOMs 
which  constitute  standardised  FOMs  which  can  be  used  by  a  given  community.  The 
most  notable  reference  FOM  is  the  Real-time  Platform  Reference  FOM  (RPR-FOM)  that 
was  designed  to  cover  all  the  needs  of  the  real-time,  interactive  simulation  community 
who  had  previously  employed  DIS.  Looking  at  the  RPR-FOM  definition,  it  is  clear  that 
there  is  a  basic  mapping  of  DIS  features  into  the  HLA  world.  ESPDUs  are  replaced  by 
objects  publishing  their  location  and  velocity  vectors,  whilst  fire  and  detonation  PDUs 
are  replaced  with  interaction  classes.  However  the  RPR-FOM  does  provide  some 
degree  of  HLA  plug  and  play  with  many  commercial  applications  now  supporting  the 
FOM.  Caution  must  be  taken  though  as  there  have  been  various  versions  of  the  FOM 
defined  as  it  has  matured  and  later  versions  are  not  backwards  compatible.  Currently, 
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the  majority  of  commercial  applications  specify  the  RPR-FOM  version  0.7.  The 
EXC3ITE  HLA  Track  Federate,  developed  as  part  of  the  recent  FILA/EXC3ITE  project, 
uses  Version  1.0  of  the  RPR-FOM  in  order  to  maximise  alignment  with  the  EXC3ITE 
track  standard  and  hence  will  not  operate  with  Version  0.7.  Additionally,  the  RPR- 
FOM  is  US  centric  and  would  require  some  minor  additions  to  represent  Australian 
ORBATs  and  interests. 

The  RPR-FOM  does  provide  a  limited  solution  to  interoperability,  but  at  the  cost  of 
flexibility.  If  we  simply  adopt  the  RPR-FOM,  we  gain  little  over  DIS.  In  particular,  one 
of  the  major  deficiencies  with  DIS  is  its  inability  to  easily  address  C2  issues,  issues 
which  are  significant  to  EXC3ITE  given  its  C3I  enabling  qualities  and  the  need  for 
simulation  services  that  provide  linkage  and  interoperate  with  real  world  C3I  systems. 
There  is  a  requirement  for  simulations  to  be  able  to  explicitly  generate  and  respond  to  a 
range  of  orders,  reports  and  requests.  Simulated  surveillance  assets  need  to  be  able  to 
issue  detections  using  appropriate  messages  that  are  reported  via  realistic  simulated 
reporting  chains  and  manifest  within  real  C3I  systems15.  Simulated  or  real  commanders 
and  their  agencies  must  be  able  to  direct  simulated  assets  using  appropriate  messages 
that  are  conveyed  via  realistic  simulated  command  chains.  Standard  DIS16  protocols 
and  the  RPR-FOM  will  not  support  such  interactions;  to  get  down  to  this  level,  we  need 
explicit  C2  representation  within  the  simulation  environment  which  can  be  accessed 
externally.  To  satisfy  this  requirement,  the  recent  FILA/EXC3ITE  produced  an  HLA- 
enabled  version  of  the  Distributed  Interactive  C3I  Effectiveness  (DICE)  simulation.  The 
DICE  C2  SOM  employs  formatted  textual  messages  and  their  atomic  elements  to 
convey  orders,  reports  and  requests.  DICE  SOM  libraries  can  be  provided  to  other 
federates  to  enable  their  use  of  the  SOM.  No  standardised  reference  FOM  exists  for  the 
representation  of  C2  information,  and  hence  off-the-shelf  compatibility  is  again 
unlikely. 

FOM  Bridges 

One  solution  to  the  problem  of  incompatible  FOMs  is  the  bridge.  A  FOM  bridge  is 
basically  a  federate  that  is  part  of  two  HLA  federations.  It  can  take  information  from 
one  federation  and  where  appropriate,  generate  updates  and  interactions  for  the 
second  federation. 


15  A  focus  area  under  TTCP  JSA  Group  TP2  (Modelling  and  Simulation)  has  been  established  to  explore 
“Simulation-C4ISR  Interoperability”;  Mike  Davies  (ITD)  is  the  Australian  Focus  Officer. 

16  In  some  packages,  such  as  ModSAF,  the  range  of  DIS  PDUs  has  been  extended  to  allow  Command  & 
Control  Simulation  Interface  Language  (CCSIL)  messages,  which  can  be  used  to  send  and  receive  C2 
information  between  simulations.  The  design  rationale  of  CCSIL  was  flawed  in  that  the  messages  were 
reinventions  of  real  world  messaging  formats;  implementation  of  CCSIL  was  limited;  funding  has  since 
been  cut  by  DMSO. 
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Figure  6:  Illustration  ofFOM  bridging 


Bridges  may  also  be  used  for  converting  from  other  simulation  protocols  to  a  given 
HLA  protocol,  for  example  from  DIS  to  the  RPR-FOM,  for  which  many  commercial 
bridges  exist.  The  main  drawback  with  bridges  is  that  they  become  a  bottleneck 
through  which  all  inter-federation  traffic  must  pass.  In  addition,  as  more  and  more 
federations  are  to  be  bridged,  the  solution  is  not  scalable,  with  a  unique  1:1  federation 
bridge  required  for  each  pair  of  federates  (unless  some  intermediary  language  was 
used,  adding  to  the  bottleneck).  Mixing  3  federations  would  need  3  bridges, 
4  federations  requiring  6  bridges  and  5  needing  10,  etc.  However  if  only  a  couple  of 
FOMs  were  defined  for  use  within  EXC3ITE,  then  bridges  may  provide  an  effective 
solution  to  interoperability  for  limited  size  exercises. 


RTI  Hierarchical  Federations 

A  research  group  at  Alenia  Marconi  Systems  in  the  UK  has  developed  a  concept  of 
hierarchical  federations  (ref)  under  contract  for  the  DERA  in  the  UK.  Hierarchical 
federations  use  an  adapted  RTI  to  provide  similar  capabilities  to  bridging  federates, 
but  in  a  more  efficient  manner.  The  new  RTI  would  require  information  about  the  two 
federates  it  is  connected  to  and  would  be  capable  of  transferring  information  where 
appropriate  between  them.  It  would  also  be  possible  to  allow  time  management 
information  to  be  transferred  between  federations,  which  could  be  problematic  using  a 
straight  bridging  approach. 

Certainly  their  description  of  hierarchical  federations  may  provide  a  more  flexible 
solution  to  intra-federation  communication  that  is  possible  using  just  bridges. 
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Agile  FOMs 

There  is  some  push  in  the  US  DMSO  to  define  a  specification  for  Agile  FOMs.  These 
are  basically  a  meta-FOM  which  can  describe  actual  object  meanings  within  the 
simulation.  It  is  then  possible  to  match  the  object  names  and  representations  used 
locally  within  a  given  simulation  with  the  overall  federation  FOM,  providing  a  run¬ 
time  mapping.  Using  this  approach,  it  should  be  possible  to  provide  a  greater  degree  of 
interoperability  between  federates  using  different  names  for  similar  objects.  A  problem 
may  still  occur  however  if  a  different  representation  is  used  for  a  given  instance,  for 
example  different  grid  coordinate  representation  methods. 

If  the  DMSO  agile  FOM  work  is  standardised,  COTS  applications  will  come  with  a 
specification  of  their  internal  object  names  and  representations,  which  would  be  used 
as  input  to  the  DMSO  tools  to  create  mappings  onto  the  FOM.  The  long-term 
scalability  and  flexibility  offered  through  this  approach  is  yet  to  be  validated,  although 
it  certainly  holds  promise. 

Development  of  the  HLA-enabled  version  of  DICE  made  use  of  its  standard  internal 
language  to  arrive  at  a  comparable  capability  to  that  of  the  agile  FOM.  DICE  can 
accommodate  any  FOM,  without  the  need  for  software  development,  by  specifying 
appropriate  mapping  data  that  is  used  for  rim- time  interpretation  and  creation  of  C2 
messages. 

FOM  Hierarchies 

As  an  HLA  FOM  is  a  hierarchical  definition  of  the  objects  and  interactions  within  a 
federation,  it  is  possible  to  use  this  hierarchy  to  provide  interoperability  between 
federates  for  different  subsets  of  the  FOM.  As  an  example,  the  FOM  may  define  a  basic 
entity  type  with  some  sort  of  descriptor  field  and  a  location.  Below  this  the  FOM  may 
go  on  to  distinguish  between  land,  maritime  and  air  entities.  Land  entities  may  then  be 
broken  down  further  into  dismounted  infantry,  tracked  vehicles  and  wheeled  vehicles. 

For  each  federate  within  the  federation,  it  is  possible  for  their  individual  SOM  to  only 
include  the  information  which  they  are  interested  in  representing.  A  maritime 
federate's  SOM  would  include  all  of  the  detailed  ship  modelling,  but  only  represent 
land  vehicles  at  the  Land  entity  level,  ignoring  the  lower  detail. 
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Figure  7:  Example  model  hierarchy. 

Using  the  feature  of  HLA,  we  could  have  individual  interest  groups  define  their  subset 
of  the  FOM  and  merge  these  into  the  final  standard.  The  only  condition  is  that  at  the 
higher  level,  the  SOMs  must  be  compatible  -  the  maritime  FOM  definition  group  must 
use  the  same  basic  tree  structure  at  the  top  as  the  other  groups. 

Using  this  approach,  it  would  be  possible  to  define  a  minimum  standard  to  which  all 
EXC3ITE  federates  must  be  able  to  interoperate.  The  obvious  choice  for  this  would  be 
the  (Australianised)  RPR-FOM.  Below  die  RPR-FOM  we  could  then  define  interest 
area  specific  hierarchies,  for  example  a  whole  branch  dedicated  to  C2,  another  to 
communications,  one  to  sensor  modelling,  etc.  Provided  all  groups  accept  the  RPR- 
FOM  as  the  basic  starting  point,  then  at  least  at  the  entity  level,  interoperability  is 
assured.  Some  suggested  interest  areas  for  a  FOM  working  group  could  be: 

•  C2  messaging  -  orders,  reports  and  requests  between  physical  domain  simulations 
and  simulated  and/or  real  C3I  systems  (building  on  the  recent  HLA/EXC3ITE 
project)17 

•  Naval  sub-systems,  building  on  the  virtual  ship 

•  EW  modelling,  covering  the  spectrum  of  EW  capability  and  the  electromagnet 
spectrums  required  to  model  this 

•  Comms  modelling,  built  around  CD's  proposed  HLA  comms  models 

•  Information  operations,  possibly  a  subset  of  the  EW 

•  Sensor  modelling,  using  detailed  physics  based  sensor  models 

Each  working  group  would  design  their  subset  of  the  overall  FOM  to  be  compatible 
with  the  other  groups,  but  built  from  the  basic  RPR-FOM.  The  working  groups  could 
meet  and  manage  their  subset  in  a  similar  manner  to  the  Track  services  working  group 
already  within  EXC3ITE.  However  the  complexity  and  management  required  to 
facilitate  such  an  approach  should  not  be  underestimated,  with  significant  resources 
required  (in  terms  of  time)  for  the  development  of  a  complete  FOM. 


17  A  collaborative  program  of  work  has  been  established  between  ITD  and  Boeing  Australia  to  explore  the 
significance  of  HLA  to  C2.  The  collaboration  will  bring  together  DICE  HLA  capabilities  and  the  meta-FOM 
(or  object  model  atoms)  capabilities  of  the  Boeing  Australia  Synthetic  Environment  (BASE). 
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3.3.4  Networked  Game  Consoles 

Beside  the  standard-based  future  of  HLA,  which  is  largely  US  DOD  driven, 
alternatives  exist  for  distributed  simulation.  The  entertainment  industry,  and  the 
computer  games  industry  in  particular  is  producing  sophisticated  simulation  systems 
based  on  very  powerful  computer  architectures  with  advanced  visualisation,  and 
integrated  network  data  exchange  capabilities18.  These  games  already  are  available 
with  development  environments,  to  allow  enthusiasts  to  develop  their  own  entities  / 
components  and  stories  /  scenarios.  This  allows  the  manufacturers  to  gain  an  increased 
market  share  by  leveraging  off  free  talent,  who  provide  increased  functionality  of  their 
products.  Similarly,  for  DSTO,  if  the  cost  of  software  reuse  proves  too  high,  networked 
games  platforms  running  custom-developed  code  poses  a  potentially  very  low  cost 
alternative  to  a  heavy  standards-based  approach. 

The  fortunes  of  the  games  industry,  more  than  any  other  entertainment  media,  are 
inextricably  linked  to  the  development  of  new  hardware  platforms.  Every  new  console 
machine  launched  has  a  typical  lifecycle  of  four  or  five  years  before  it  is  superseded  by 
a  new  generation  of  more  powerful  platforms. 

4.  Recommendations 

Structure,  Process  and  Next  Steps 

•  This  paper  be  treated  as  a  living  document,  with  responsibility  for  further 
development  handed  over  to  a  focus  area  under  the  management  of  the  DSTO 
Simulation  hub. 

•  As  part  of  the  focus  area,  establish  an  EXC3ITE  Simulation  Services  Working 
Group  (ESSWG)  to  oversee  development  of  the  EXC3ITE  Simulation  Architecture 
(ESA).  The  ESSWG  will  be  a  joint  DSTO-Industry  forum  formed  explicitly  for  this 
purpose.  Mechanisms  for  industry  involvement  in  the  ESSWG  can  evolve  with 
guidance  from  the  recently  formed  Defence  Simulation  Advisory  Forum  (DSAF) 
chaired  by  the  Director-General,  Simulation  (DGSIM)  in  ADHQ.  The  President  of 
the  Simulation  Industry  Association  of  Australia  (SIAA)  is  also  a  member  of  the 
DSAF.  The  ESSWG  will  endorse  a  broad  statement  of  requirement  for  the  ESA  and 
shall  call  for  proposals  for  components  of  it.  Proposals  shall  be  based  on  existing 
solutions,  or  proposed  solutions  that  can  be  readily  implemented  to  prove 
underlying  concepts.  The  ESSWG  will  endorse  proposals  for  components  of  the 
ESA.  The  operation  of  the  ESSWG  shall  be  governed  by  Terms  of  Reference  drawn 
directly  from  the  model  of  the  Virtual  Ship  Architecture  Working  Group  terms  of 
reference  (Appendix  I). 


18  See  the  report  “Modeling  and  Simulation  -  Linking  Entertainment  and  Defense”  1997,  Online  at: 
http://bob.nap.edu/readinaroom/books/modelinq/ 
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•  Based  on  the  aggregated  information  from  the  "use  cases",  the  ESSWG  develop  a 
priority  list  of  services  for  development.  The  priority  services  should  be  further 
scoped  and  costed  for  EXC3ITE  funding  well  prior  to  the  end  of  FY00/01. 

•  RLMIE  accept  responsibility  to  develop  a  second  phase  of  EXC3ITE  (proposal  for 
FY01/02),  incorporating  the  development  of  enduring  simulation  services.  This 
proposal  be  shaped  by  the  focus  area,  recommendations  by  the  ESSWG,  the 
Defence  Simulation  Advisory  Forum  (DSAF)  and  the  test  and  evaluation 
community  (eg  DTRIALS). 

Technical  Issues  for  Further  Investigation 

•  Based  on  practical  experience  of  simulation  to  limit  the  scope  of  activity,  the 
ESSWG  develop  and  evolve  an  architecture  for  secure  interaction  between  real 
and  simulated  information  and  infrastructure. 

•  Endorse  the  use  of  HLA  and  DIS  with  an  EXC3ITE  administered  DIS-HLA  bridge 
being  provided  for  interoperability  between  the  two  environments,  and  pursue  the 
development  of  a  DIS-HLA  bridge  as  a  priority. 

•  The  simulation  hub  continue  to  monitor  and  assess  the  capabilities  of  simulations 
developed  by  the  entertainment  industry,  as  a  viable  contender  to  the  heavily 
standards-based  approaches  of  HLA  and  DIS. 

•  EXC3ITE  will  provide  QOS  managed  services  for  both  HLA  and  DIS  simulations. 

•  HLA  FOM  interoperability  be  addressed  by  a  FOM  working  group  in  the  focus 
area  to  define  the  top-level  Australian  FOM,  based  around  the  RPR-FOM  if  found 
suitable.  A  number  of  application  area  working  groups  can  then  begin  to  tailor 
their  specific  FOM  subsets  for  incorporation  into  the  overall  EXC3ITE  endorsed 
FOM.  This  be  backed  up  by  publishing  and  promulgating  the  base  FOM 
throughout  DSTO  and  the  EXC3ITE  community. 

•  It  be  recognised  that  certain  areas  may  decide  that  the  chosen,  RPR-FOM  based 
FOM  is  not  applicable  or  suitable  for  their  interests.  Such  areas  may  include  those 
undertaking  detailed  engineering  simulations  or  non-entity  based  modelling. 
Simulations  that  hold  a  clear  case  for  non-interoperability  with  EXC3ITE 
federations  should  meet  no  impediment  to  developing  their  own  FOM.  They 
may  still  wish  to  utilise  the  remainder  of  the  (simulation)  services  on  EXC3ITE  and 
so  support  should  still  be  provided  for  their  use. 

•  DSTO  Chiefs  demonstrate  their  understanding  of  the  significance  of  the  level  of 
effort  required  to  develop  these  services,  and  provide  the  level  of  commitment 
(priority  and  resources)  to  pursue  the  work. 
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Appendix  A:  The  Vision  for  Simulation  in  Defence 

Introduction 

The  Australian  Defence  Organisation  (ADO)  will  use  simulation  to  enhance  Australian 
Defence  Force  (ADF)  capabilities,  save  resources  and  reduce  risk. 

The  fundamental  process  from  which  such  benefits  emerge  can  be  described  simply  as 
the  gaining  and  sustaining  of  knowledge  by  the  use  of  simulation. 

Defence  will  look  increasingly  to  simulation  to  take  better  account  of  the  complexity,  the 
dynamics  and  the  uncertainties  that  pervade  modern  warfare. 

Areas  of  Use  and  Benefit 

Simulation  will  provide  a  readily  available,  flexible  and  cost-effective  means  to 
enhance  ADF  capabilities  in  the  areas  of  defence  analysis  and  planning,  research  and 
development,  force  development,  acquisition,  training  and  support  to  real  operations. 

Simulation  facilities  will  provide  realistic  representations  of  activities  in  warfare,  crisis 
management  and  peace  support  operations.  These  will  include  interactions  with 
civilian  organisations  and  authorities  as  required. 

Simulation  approaches  will  enable  Defence  to  plan  its  operations  and  its  investments 
more  wisely. 

Simulation  will  allow  ADF  personnel  to  train  in  their  normal  working  environment 
and  to  interact  realistically  with  other  staff  -  or  with  simulations  of  other  staff.  The 
connection  of  simulations  to  existing  and  future  ADF  Command  Support  Systems  will 
be  routine. 

Live  exercises  will  be  enriched  by  (and  in  some  cases  replaced  by)  simulations  to 
improve  realism,  allow  operations  to  be  experienced  that  are  otherwise  impractical  to 
conduct  in  peacetime,  reduce  the  cost  of  training  and  reduce  adverse  impacts  on  the 
natural  environment. 

Simulation  approaches  will  provide  representations  of  the  real  world  to  stimulate 
evolutionary  improvements  in  almost  all  aspects  of  ADF  operations.  They  will  facilitate 
analyses  of  complex  decisions  facing  Defence  leaders  and  improve  the  mission 
readiness  of  Australia's  forces. 

Simulation  facilities  will  be  able  to  integrate  a  mix  of  computer  simulations,  actual  war 
fighting  systems  and  military  system  simulators.  Components  of  that  mix  may  well  be 
geographically  distributed.  The  resulting  capabihties  will  allow  detailed  exploration  of 
simulated  missions  and  related  key  aspects  of  operational  environments. 

Technical  challenges  will  be  met  so  that  reusable  simulation  components  can  work 
with  others  to  offer  the  maximum  capability,  flexibility  and  cost-effectiveness.  This  will 


39 


DSTO-GD-0270 


become  possible  as  Defence  adopts  the  necessary  technical  standards  being  developed 
in  concert  with  Australia's  international  partners. 

Simulation  will  continue  to  provide  a  powerful  tool  to  support  research  (including 
studies  and  analyses)  and  to  develop  Defence  technology.  Such  simulation  capabilities 
will  also  find  productive  use  in  support  to  the  acquisition  process. 

Representations  of  proposed  systems  within  simulated  operational  environments  will 
support  phases  of  the  acquisition  process  from  requirements  determination  and  initial 
concept  exploration  to  the  manufacture,  test  and  evaluation  of  new  systems. 

Early  operational  assessments  via  simulation  of  new  systems  and  system  upgrades  will 
be  examined  for  their  operational  and  logistical  impact  prior  to  investment  decision.  As 
a  result,  military  system  requirements  may  well  be  advantageously  refined.  Cost  and 
operational  effectiveness  assessments  will  be  rendered  more  credible  and  persuasive. 

Assessment  via  simulation  will  improve  the  quality  of  information  available  to 
influence  resource  allocation  decisions.  Continuing  evaluations  in  the  relevant 
simulated  operational  environments  during  system  development  will  improve 
engineering  trade-off  analyses  and  ensure  that  the  final  product  best  satisfies  ADF 
needs. 

Simulation  will  enable  tests,  evaluations  and  analyses  otherwise  infeasible  because  of 
limited  test  resources,  environmental  restrictions  or  safety  constraints. 

Simulation  will  enhance  the  sharing  of  information  among  designers,  manufacturers, 
logisticians,  testers  and  users.  Increased  dialogue  among  these  groups  will  promote 
more  effective  interaction  between  the  operational  and  acquisition  communities. 

Key  Drivers 

This  vision  will  be  achieved  via  a  Defence- wide  co-operative  effort  that  ensures 
affordable  simulation  development,  interoperability  and  reusability.  The  necessary 
effort  and  its  results  will  therefore  have  the  following  attributes: 

a.  Funding  will  be  coordinated  centrally  when  appropriate  and  distributed  across  the 
relevant  Defence  stakeholder  communities; 

b.  Military  personnel  will  interact  with  simulated  mission  activities  in  the  same  way 
they  interact  with  the  real  world  by  using  operational  systems  with  which  they  are 
familiar; 

c.  Developments  will  allow  the  linking  of  self-contained  simulations,  human-in- the- 
loop  simulators  and  personnel  using  real-world  equipment  as  appropriate  for  user 
purposes; 

d.  Simulation  systems  will  be  interoperable  and  reusable  to  the  maximum  practical 
extent; 

e.  Enduring  technical  standards  will  emerge  that  allow  ready  composition  of  diverse 
simulated  activities  to  satisfy  the  broad  range  of  existing  and  emerging  needs; 
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f.  Work  on  simulation  approaches  will  develop  and  combine  the  use  of  the 
capabilities  of  government,  local  industry  and  academia; 

•  Simulation  facilities  will  be  provided  by  using  existing  government  off-the-shelf 
and  commercial  off-the-shelf  software  and  hardware.  Modification  of  these 
items  or  the  building  of  new  items  will  only  take  place  where  required  and  cost- 
effective; 

g.  Simulations  will  be  verified,  validated  and  accredited  for  their  intended  purpose; 

h.  Simulation  systems  will  accommodate  where  necessary  the  security  needs  of  the 
Defence  Information  Environment; 

i.  Activities  will  secure  mutual  benefits  from  fostering  co-operation  with  Australia's 
traditional  and  non-traditional  allies; 

Key  Requirements 

Integrated  high-level  simulated  mission  spaces  that  support  the  ADF  in  the  principal 
application  areas  of  defence  planning,  training,  exercises  and  support  to  operations; 

Standard  tools  and  services  to  support  employment  of  the  principal  applications; 

A  capability  to  operate  seamlessly  with  existing  and  planned  ADF  operational  CIS  such  that  the 

simulation  is  transparent  to  users ; 

Interoperability  with  allied  simulation  systems  to  support  the  training  of  multi¬ 
national  forces  for  coalition  operations; 

A  reduced  requirement  for  directing  staff  and  response  cells  by  providing  an 
automated  representation  of  friendly  and  opposing  force  actions,  as  well  as  the 
response  of  the  operational  command  structure; 

A  capability  to  conduct  comprehensive  post-exercise  analyses  that  can  reconstruct 
events  and  derive  lessons  for  users  in  real-world  operations; 

Representation  of  the  highest  priority  land  masses,  hydrographic  regions,  the 
atmosphere,  space  and  weather,  along  with  application  programs  to  access  and 
manipulate  the  databases; 

A  database  of  representative  fixed  installations,  generic  enemy  order-of-battle  (OOB), 
actual  friendly  forces  OOB  and  realistic  weapon  system  attributes. 
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Appendix  B:  Challenges  facing  the  Modelling  and 
Simulation  community 

Introduction 

A  key  reminder  emerging  in  1999 from  deliberations  by  the  US  National  Research  Council  ran 
as  follows: 

"History  is  littered  with  plans ,  both  strategic  and  tactical ,  that  were  conceptually  brilliant,  but 
failed  because  the  barriers  to  success  were  not  carefully  considered." 

With  this  cautionary  note  in  mind,  what  does  need  to  be  identified  for  careful 
consideration  before  the  full  potential  of  modelling  and  simulation  in  Defence  can  be 
realised? 

The  potential  barriers  to  success  are  recognised  as  challenges  in  the  following  three 
related  domains: 

•  Challenges  with  Culture,  Management,  and  Economics; 

•  Challenges  with  Information  Management; 

•  Challenges  with  the  Integration  of  Tools,  Systems,  and  Data. 

The  sections  below  summarise  these  challenges.: 

Challenges  with  Culture,  Management,  and  Economics 

a.  Difficulty  justifying  strong  corporate  commitment  to  implementing  collaborative 
technologies  because  of  their  complexity  and  uncertainties  regarding  costs,  metrics, 
and  benefits; 

b.  How  do  you  encourage  the  necessary  collaboration  across  organizational 
boundaries? 

c.  Unknowns  concerning  the  total  costs  of  implementing  collaborative  technologies 
and  systems  and  the  return  on  investment.  Resource  savings  are  a  motivator; 

d.  High  initial  and  maintenance  costs  of  new  collaborative  technologies  and  systems 
in  a  cost  constrained  environment; 

e.  Risk  -  someone  has  to  assume  the  risk  -  once  identified,  how  is  this  to  be  shared 
between  Defence  and  Industry?  Risk  reduction  is  a  motivator. 

f.  Planning  and  timing  issues  -  when  to  bring  in  the  new  and  retire  the  old? 

g.  Difficulty  managing  constant  change  as  vendors  continually  upgrade  tools  and 
other  technologies; 
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h.  Client  acceptance  -  the  substantial  challenges  for  the  Modelling  and  Simulation 
arena  represented  by  Verification,  Validation  and  Accreditation  responsibilities; 

i.  Human  Factors  aspects  -  how  does  an  organisation  overcome  its  culture/practices 
barriers  to  avoid  technology  being  ineffective  through  misuse  or  non-use.? 


Challenges  with  Information  Management 

a.  Difficult  to  maintain  configuration  management  for  product  designs,  processes, 
and  resources; 

b.  Need  to  provide  system  agility  so  different  users  can  easily  input,  extract, 
understand,  move,  change,  and  store  data  using  familiar  formats  and  terminology; 

c.  Difficulty  upgrading  internal  infrastructures  to  support  large  band  widths 
associated  with  sharing  of  data  and  information; 

d.  Need  to  provide  system  security  and  to  protect  proprietary  data  without  degrading 
system  efficiency. 


Challenges  with  the  Integration  of  Tools,  Systems,  and  Data 

a.  Lack  of  tool  interoperability—  proliferation  of  tools  aggravates  interoperability 
issues; 

b.  Existing  investments  in  legacy  systems  and  difficulty  integrating  legacy  systems 
with  newer  advanced  tools; 

c.  Little  effort  by  software  vendors  to  address  interoperability/  data  exchange  outside 
of  their  own  suite  of  tools; 

d.  Multiple  hardware  platform  issues  -  computers,  hardware,  databases,  and 
operating  systems; 

e.  Lack  of  formal  or  informal  standards  for  interfaces,  files,  and  data  terminology; 

f.  Standards  that  will  free  companies  to  innovate  much  more  rapidly,  and  profitably 
than  is  possible  with  proprietary  approaches  to  encourage  focus  on  high-value 
capabilities  without  having  to  rewrite  the  architecture  or  interface; 

g.  Increasing  complexity  of  tools  calling  for  a  collaborative  environment  capability; 

h.  Difficulty  of  inserting  emerging  and  advanced  technologies,  tools,  and  processes 
into  current  product  and  service  environments; 

i.  Supplier  integration  issues; 
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Appendix  C:  Utility  of  Simulations  and  Synthetic 
Environments  to  Strategic  and  Operational-level 

Issues 

Modelling  and  simulation  can  significantly  enhance  operational  planning  and 
command  decision  making  at  the  strategic  and  operational  levels.  EXC3ITE  has  a  key 
role  through  initial  concept  and  capability  demonstration  and  experimentation,  plus  a 
capability  enabling  operational  'reach'  into  DSTO  and  possibly  industry.  An  integrated 
modelling  environment  (In-MODE)  is  essential  here,  ie  one  that  enables  staff  to  work  at 
their  appropriate  level  but  with  the  ability  to  explore  issues  of  detail  by  navigating  up 
and  down  a  spectrum  of  models  and  simulations  as  required.  Simulations  and 
synthetic  environments  of  the  nature  largely  considered  for  'EXC3ITE  simulation 
services'  therefore  have  utility  in  operational  planning  and  command  decision  making 
at  the  strategic  and  operational  levels  but  within  the  In-MODE  spectrum.  The  spectrum 
would  need  to  integrate  a  range  of  causal,  temporal  and  spatial  models  in  order  to 
enable: 

•  Modelling  and  analysis  of  indicators  and  warnings,  Pol-Mil-Soc-Econ  sensitivities 
and  other  issues;  sensitivities  to  transactions  of  national  power; 

•  Support  to  the  architecting  through  to  rehearsal  of  operational  plans; 

•  Effects-based  analysis  through  influence-effect-consequence  and  constraint 
modelling; 

•  The  integration  of  target  systems  analysis  models; 

•  Temporal  and  spatial  issues  of  courses  of  action  (CO A); 

•  The  early  priming  of  unwarranted  courses  of  action  through  tools  that  enable  the 
mapping  of  critical  vulnerabilities  through  to  centres  of  gravity; 

•  The  ability  to  employ  detailed  models  of  logistics,  attrition  and  weapon  and 
platform  performance  as  required; 

•  Simulated  COA  execution  in  time  and  space; 

•  Interactive  'Blue  against  Red'  wargaming  and  rehearsal  of  selected  COA; 

•  Strong  cross-population  of  models  such  that  simple  models  permit  focussed  use  of 
'expensive'  detailed  models  and  simulations  and  detailed  models  provide  shaping 
factors  for  simple  models;  and 

•  Integration  with  operational  and  other  databases  to  minimise  duplication  of  data 
entry. 

General  example: 

The  following  example  is  rather  sequential  in  nature;  in  reality  there  would  be 
numerous  iterations  and  cycles  that  employ  the  various  models  and  simulations  and 
engage  multiple  levels  of  the  ADO. 
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Routine : 

Interactive  Bayesian  influence  networks  (I&W  models)  of  regional  Pol-Mil-Soc-Econ 
situations  have  been  constructed  by  strategic  intelligence  analysts  and  maintained 
routinely  and  collaboratively  through  input  from  geographically  distributed  analysts 
from  the  operational  and  tactical  levels  taking  feeds  from  various  intelligence  and 
other  sources.  The  models  capture  the  causal  relationships  between  possible  direct  or 
indirect  influences,  key  hypotheses  of  interest  such  as  Decline  in  Foreign  Government 
Control  and  associated  threat  to  Australia  or  Australian  nationals.  The  models  have 
been  updated  based  on  observables.  The  models  provide  powerful  components  of 
strategic  Indicators  &  Warnings  (I&W)  capability.  The  models  capture  a  subjective 
assessment  aided  through  reference  to  detailed  econometric,  cultural  and  other 
models.  The  I&W  models  have  been  routinely  used  for  instability  prediction  and  to 
determine,  observe  and  analyse  sensitivities  and  pressure  points  and  to  advise 
Government  on  issues  concerning  diplomatic  influences. 

Also  developed  routinely,  drawing  on  intelligence  sources  and  domain  expertise  from 
strategic  intelligence  and  Theatre  components,  is  a  suite  of  dynamic  target  systems 
analysis  models  (TSA  models).  The  models  are  maintained  routinely  through 
prioritised  intelligence  collection  and  integration  with  dynamic  intelligence  databases 
and  are  accredited  intelligence  products.  The  models  consider  a  potential  'enemy  as  a 
system',  help  manage  and  analyse  intelligence  gaps,  and  embrace  system 
dependencies,  behaviour  in  time  and  space,  flows,  processes,  performance,  recovery, 
criticalities  and  vulnerabilities.  The  system  models  make  reference  to  detailed  models 
of  platform  performance,  weapons,  sensors  and  natural  environment. 


Increasing  tension: 

A  prediction  of  increased  turmoil  in  particular  areas  of  the  region  results  in  the  issuing 
of  a  warning  order  and  military  strategic  estimate  to  the  Theatre  that  triggers  off 
deliberate  through  to  immediate  planning.  The  I&W  models  are  part  of  the  warning 
order  package  and  give  an  increased  awareness  to  theatre  planners  of  the  associated 
strategic  issues.  The  I&W  models  are  updated  as  events  occur  and  national  and 
international  political  and  other  non-military  influences  made.  Operationally  focussed, 
lower-level  but  integrated  I&W  models  are  developed  and  maintained  by  the 
operational  intelligence  staff. 

COMAST  defines  constraints  and  military  end  state  (the  why  of  COA)  in  terms  of 
adversarial  centres  of  gravity  (CoG,  eg  force  projection).  A  quantified  causal  model  is 
built  that  describes  friendly  and  adversarial  CoG  and  their  dependency  on  critical 
vulnerabilities  (CV,  eg  communications,  POL  supply  points,  ...)  taking  into  account 
cultural  and  other  factors.  The  TSA  models  are  now  employed  by  the  operational 
intelligence  staff  within  the  context  of  commander's  intent,  constraints,  military  end- 
state  and  strategic  objectives  to  aid  the  mapping  of  CV  to  CoG,  determine  validity  of 
targets  and  focus  intelligence  collection.  Pruning  of  unwarranted  COA  can  occur  in 
terms  of  target  CV  through  analysis  of  task  and  weapon  options,  strategic  Pol-Mil 
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sensitivities  and  relative  causal  effect  of  CV  influences  on  CoG.  Risk  and  cost  also 
eliminate  consideration  of  certain  options  through  awareness  of  own  vulnerabilities 
that  need  to  be  protected  and  minimised.  An  initial  list  of  candidate  hard  and  soft 
target  CV  plus  task  options  evolves  (the  what  and  how  of  COA). 

Discrete  event  dynamic  system  models  are  built  of  remaining  candidate  COA  branches 
and  sequels  that  enable  assessment  of  scheduling,  deconfliction  and  resourcing  (the 
when  and  with  what/whom  of  COA).  The  results  from  execution  of  detailed  models  of 
own  force  logistics,  information  networks,  sensors,  platforms,  and  weapons  are 
generated  and  considered  in  timings  and  probabilities.  Likelihood  and  temporal 
analysis,  eg  of  logistics  feasibility,  further  prune  the  candidate  COA  space.  The  TSA 
models  are  used  to  highlight  restricted  and  protected  targets  and  to  explore  the 
significance /criticality  of  intelligence  gaps  to  candidate  COA.  The  models  enable  an 
assessment  of  likelihood  of  detection,  response  and  attribution.  A  modified  target  list 
plus  scheduled  and  resourced  candidate  COA  evolves. 

A  distributed  simulation  is  quickly  assembled  using  interoperable  models  of  relevant 
sensors,  platforms,  weapons,  information  networks  and  C2  that  enables  particular 
COA  to  be  constructed  and  executed  in  time  and  space  (the  where  element).  R&D 
models  are  drawn  from  DSTO  as  required.  Analysts  access  detailed  radar  and  platform 
performance  models  to  satisfy  non-Janes  type  queries  regarding  the  natural 
environment  and  associated  geospatial  issues.  The  candidate  COA  space  is  narrowed 
further. 

Particular  COA  are  wargamed  by  planning  and  intelligence  staff  using  a  range  of 
techniques  including  a  distributed  C2-led  synthetic  environment  that  supports 
interactive  experimentation  by  'Blue  and  Red'  planners.  The  synthetic  environment  is 
rapidly  constructed  using  components  from  earlier  and/ or  others  of  increased  fidelity. 
The  wargamers  are  able  to  trial  opposing  COA  in  order  to  test  robustness  and  fine  time 
the  COA.  Staff  are  employed  as  response  cells  and  operators  that  act  as  intermediaries 
where  necessary  between  the  wargamers  and  the  simulations  to  ensure  the  necessary 
richness  to  the  overall  environment.  C2  simulations  are  employed  in  order  to  ensure 
awareness  of  and  experimentation  with  C2  issues. 

The  various  models  and  simulations  with  rich  visualisations  are  used  to  impart  the 
recommended  COA(s)  to  COMAST  who  decides  on  the  appropriate  action.  Alert 
orders  and  operational  instructions  are  raised  and  prioritised  target  lists  drafted. 
Simulations  are  constructed  that  support  initial  and  detailed  weaponeering,  force 
application  planning  and  trade  offs. 

Rehearsal: 

A  distributed  synthetic  environment  employing  a  mix  of  interoperable  virtual  and 
constructive  components  is  rapidly  assembled  with  scientific  support  and  enables  the 
key  component  HQs  and  lower-level  agencies  to  rehearse  the  chosen  COA.  The  overall 
configuration  includes  a  combination  of  the  real  C2  system  plus  simulations  of  systems 
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and  networks  yet  to  be  deployed.  The  rehearsal  highlights  various  issues  concerning 
execution  and  results  in  lower-level  refinement  and  increased  preparedness.  Again,  an 
opposing  force  is  represented. 

Execution,  situation  awareness  and  battle  damage  assessment: 

The  COA  is  executed;  supported  by  findings  from  influence  modelling,  the  military 
actions  are  coupled  with  diplomatic  in  order  to  increase  likelihood  of  achieving  desired 
effect.  The  TSA  and  updated  I&W  models  aid  situation  awareness  by  helping  an 
understanding  of  the  rationale,  nature  and  significance  of  prior,  current  and  possible 
future  adversary  actions.  Imagery  and  other  intelligence  is  used  in  the  assessment  of 
physical  and  functional  battle  damage;  the  TSA  models  are  used  in  the  assessment  of 
overall  systems  impact  and  aid  formulation  of  re-attack  recommendations.  The  CV  to 
CoG  models  are  used  to  dynamically  gauge  impact  on  CoG. 
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Appendix  D:  Joint  Architecture  "Use"  Case 

Description 

The  purpose  of  this  environment  is  to  facilitate  the  study  of  the  joint  awareness 
capabilities  of  the  elements  of  an  operational  scenario. 

During  an  operation,  various  ADF  elements  work  together  in  groups  to  achieve 
mission  objectives  within  varying  time  and  space  parameters.  In  terms  of  situation 
awareness,  simulations  to  date  have  concentrated  on  either  a  platform  perspective,  or  a 
headquarters  perspective  and  have  focussed  on  either  measures  of  performance 
outcomes  or  decision  making  issues. 

This  application  aims  to  provide  an  environment  within  which  information 
contributions  from  air,  land  and  sea  elements,  as  well  as  from  joint  strategic  assets,  are 
examined  for  their  relative  impacts  on  joint  situation  awareness.  Joint  situation 
awareness,  in  this  case  will  include  how  each  of  the  elements  contributes  to: 

•  its  own  situation  awareness; 

•  the  situation  awareness  of  the  other  elements  with  which  it  is  operating  to 
achieve  particular  mission  objectives  and 

•  mission  outcomes. 

This  environment  would  seek  to  model  the  information  aspects  of  each  of  the  entities  - 
the  information  that  each  element  can  acquire,  process  and  disseminate  to  the  other 
elements  of  the  task  group. 

The  elements  of  the  scenario  have  been  chosen  to  utilise  and  extend  existing 
simulations,  and  the  knowledge  gained  through  them  of  the  platforms'  Operating 
Concepts  and  capabilities. 

Example  Scenario 

This  scenario  is  named  Enforcement  of  a  Territorial  Exclusion  Zone. 

A  single  Warship  is  enforcing  an  exclusion  zone  in  the  waters  around  an  Australian 
Territory  with  a  helicopter  capability  onboard.  This  exclusion  zone  is  protecting  an 
Australian  surveillance  base  on  Australian  soil  which  consists  of  an  Army  HQ  and  a 
Ground  Based  Air  Defence  System. 

An  AEW&C  aircraft  is  operating  in  the  area.  The  AEW&C  is  undertaking  surveillance 
and  control  tasks  in  the  exclusion  zone. 
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Also  operating  in  the  area  is  an  F/A  18  fighter  aircraft,  under  the  tactical  control  of  the 
AEW&C. 

During  the  scenario,  there  will  be  an  enemy  incursion  into  protected  airspace. 

Also  during  the  scenario,  an  unknown  vessel  will  be  detected  within  the  exclusion 
zone  and  close  to  the  Australian  shore. 

When  the  AEW&C  or  GBAD  detect  the  aircraft,  they  will  make  the  information 
available  to  all  other  participants  capable  of  receiving  it. 

When  the  AEW&C  or  FFG  detect  the  vessel,  they  will  make  the  information  available 
to  all  other  participants  capable  of  receiving  it. 

Outcomes 

One  outcome  of  this  simulation  will  be  to  establish  the  relative  strengths  and 
weaknesses  of  the  situation  awareness  states  of  each  of  the  entities  at  various  points 
during  the  scenario. 

Another  outcome  will  be  an  assessment  of  how  effectively  the  joint  task  group  can 
detect,  identify,  and  respond  to  the  enemy  aircraft  and  vessel. 

Entities 

The  entities  within  this  scenario  can  be  classified  as  detection  or  response  entities. 

The  Detection  entities  are: 

•  Warship 

•  AEW&C 

•  Army  HQ 

•  GBAD  system 
The  Response  entities  are: 

•  F/A  18 

•  Helicopter 

•  GBAD 
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Intrinsic  Behaviours 

Table  D-l:  Intrinsic  behaviours. 


Entity 

Behaviour 

Inputs 
(description, 
rate,  fidelity) 

Outputs 

(description,  rate, 
fidelity) 

Fidelity 

Detection 

Warship 

Detects  vessels. 
Intercepts  vessels 

Radar  signal. 
Message,  Voice 

Own  position. 
Detections,  Tracks, 
Status  Data 
(Message,  Voice) 

Med 

AEW&C 

Detects  vessels. 
Detects  aircraft. 
Controls  friendly 
aircraft  and  vessels 

Radar  signal. 
Message, 

Own  position. 
Detections,  Tracks, 
Status  Data, 
Commands 
(Message,  Voice) 

High 

Army  HQ 

Commands  and 
controls  the  GBAD 

Track 

Commands 

High 

GBAD 

system 

Detects  aircraft 

Radar  signal 

Detections,  Tracks 
(Voice,  Message) 

Med 

Response 

F/A  18 

Intercepts  vessels. 
Intercepts  aircraft 

Voice, 

Message?, 

Radar  Signal 

Status  Data  (Voice) 

Low 

Helicopter 

Intercepts  vessels 

Voice, 

Message?, 

Radar  signal 

Own  position. 
Detections,  Tracks, 
Status  Data  (Voice, 
Message?) 

High 

GBAD 

system 

Intercepts  aircraft 

Radar  signal 

Detections,  Tracks 
(Voice,  Message) 

Med 

Static  Relationships 

Table  D-2  Static  Relationships 


m\  U  I'l  II 1  'Hi1— 

Is  composed  of  low  level  entities 
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Interactions 

Table  D-3  Interactions. 


Initiating  entity 

Interaction 

Receiving  entity 

Warship 

Deploys 

Helicopter 

Warship 

Sends  Message,  Tracks 

Helicopter, 
AEW&C,  GBAD, 
Army  HQ 

AEW&C 

Commands 

F/A18 

AEW&C 

Sends  Message,  Tracks 

F/A  18, 

Helicopter, 

GBAD,  Warship, 
Army  HQ 

Helicopter 

Sends  message 

Warship, 

AEW&C 

Army  HQ 

Commands 

GBAD 

GBAD 

Sends  message.  Tracks 

Army  HQ, 
AEW&C,  F/A  18, 
Warship 

Scenario  Execution 
Tasks 

The  Warship  operates  detection  devices. 

The  AEW&C  operates  detection  devices. 

The  GBAD  operates  detection  devices. 

The  enemy  aircraft  enters  protected  airspace. 

The  enemy  vessel  appears  in  restricted  waters. 

Information  is  exchanged  between  interacting  entities. 

Time  slices  of  relative  situation  awareness  for  each  entity  is  captured. 
Command  and  control  of  the  response  entities  is  (to  be  decided). 

Initial  conditions 

The  warship  is  located  at  a  given  position,  with  a  given  speed  and  course. 
The  helicopter  is  attached  to  the  warship. 

The  F/ A  18  is  located  at  a  given  position,  with  a  given  speed  and  course. 
The  GBAD  is  located  at  a  fixed  position. 

The  AEW&C  is  located  at  a  given  position,  with  a  given  speed  and  course. 
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Termination  conditions 

Enemy  aircraft  is  identified  and  intercepted. 
Enemy  vessel  is  identified  and  intercepted. 
Enemy  aircraft  reaches  Australian  shoreline. 
Enemy  vessel  reaches  Australian  shoreline. 


Figure  D-l:  Operational  Concept  -  Platform  Placement 
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Figure  D-2:  Operational  Concept  -  Communication  (Green)  and  Surveillance  (Red) 


Example 


HQ 


AEW&C 


Enemy 


0 

F/A18 


Figure  D-3:  Command  (Red)  and  Control  (Green)  Relationships 
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Figure  D-4:  Information  flows. 
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Appendix  E:  Maritime  Architecture  "Use"  Case 

Description 

The  DSTO  Takari  program  is  concerned  with  the  role  that  information  plays  in  modem 
warfare.  Information  itself  has  no  value  if  it  does  not  enhance  the  effectiveness  of 
operations  and  making  such  an  assessment  is  at  the  heart  of  the  tactical  testbed 
concept. 

The  tactical  testbed  concept  calls  for  the  existence  of  a  human-in-the-loop  simulation 
environment  in  which  missions  can  be  simulated  and  the  impact  upon  operational 
effectiveness  of  enhanced  information  availability  assessed.  In  particular,  connecting 
the  Virtual  Ship  as  a  node  of  EXC3ITE  will  facilitate  access  to  the  services  that  provide 
data  such  as  imagery,  military  geographic  information  (MGI)  and  operational  pictures. 
The  Virtual  Ship  will  be  configured  to  represent  in-service  platforms  and  immersed  in 
a  synthetic  environment  that  includes  high  fidelity  representations  of  the  threat 
environment.  As  the  scenario  unfolds,  the  information  available  to  the  ship  through  its 
organic  sensors  will  be  supplemented  by  that  available  from  EXC3ITE.  As  an  example, 
a  tactical  picture  combining  data  from  AEWC  and  JORN  may  cue  the  ship  to  the 
existence  of  an  inbound  air  threat,  beyond  the  horizon. 

In  addition  to  supporting  an  assessment  of  the  impact  of  information  on  operational 
outcomes,  this  process  will  support  integration  of  C4ISR  systems  with  the  ship's 
combat  system  and  the  development  of  tactics  and  procedures  that  exploit  information 
availability. 

Particular  investigations  supported  by  this  capability  are  as  follows. 

1.  Assessment  of  the  value  of  information.  Through  the  conduct  of  simulated  missions  both 
supported  by  access  to  enhanced  information  and  not,  some  assessment  of  the  value  of 
the  information  in  terms  of  operational  outcomes  will  be  made. 

2.  Development  of  procedures  and  tactics  that  exploit  information.  Access  to  reliable  and 
timely  additional  information  holds  the  prospect  of  not  only  improving  operational 
effectiveness  per  se,  but  enabling  new  ways  of  conducting  missions.  The  human-in-the- 
loop  simulation  environment  will  permit  experimentation  concerning  new  procedures 
and  tactics. 

3.  Integration  of  C3I  data  within  the  combat  system.  Provision  of  information  in  a  stand 
alone  capacity  is  expected  to  have  a  positive  impact  on  operational  effectiveness. 
However,  it  is  proposed  that  effectiveness  will  be  further  enhanced  if  it  is  integrated 
with  the  ship's  combat  system  to  allow  easy  access  and  manipulation,  including  fusion 
with  the  information  provided  by  the  ship's  organic  sensors.  A  human-in-the-loop 
simulation  environment  will  provide  a  test-bed  within  which  integration  requirements 
can  be  explored. 
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Example  Scenario 

This  scenario  is  named  ?. 

A  number  of  frigates  are  escorting  a  collection  of  high  value  emits  into  an  archipelagic 
region.  There  is  a  threat  of  attack  by  hostile  aircraft  armed  with  anti-ship  cruise 
missiles.  Based  on  intelligence,  a  threat-axis  has  been  assumed  and  used  to  position  the 
ships  in  the  task  group  so  that  the  anti-ship  missile  defences  of  the  escorts  can  provide 
maximum  protection  of  the  high  value  units.  However,  if  an  attack  comes  from  a 
direction  that  deviates  too  greatly  from  the  assumed  threat  axis,  the  threat  to  the  high 
value  units  is  significantly  increased. 

Subsequent  events  may  be  explored  under  two  alternative  circumstances. 

Case  1:  The  task  group  must  rely  on  the  tactical  picture  generated  by  its  organic 
sensors  alone.  The  picture  is  therefore  horizon  limited  for  sea-skimming  anti-ship 
missiles.  The  in-bound  aircraft  will  most  likely  need  to  make  limited  use  of  radar  in 
order  to  target  the  task  group.  This  offers  the  prospect  that  electronic  support  measures 
will  provide  some  prior  warning  of  an  imminent  attack. 

Case  2:  The  area  of  operations  is  within  the  coverage  of  JORN  and  conditions  permit 
compilation  of  a  reliable  operation  picture  to  a  range  well  beyond  the  horizon  of  the 
task  groups  organic  sensors.  Through  a  satellite  link  to  the  EXC3ITE  network  the  task 
group  commander  is  being  fed  an  almost  real-time  operational  picture  (referred  to  as 
the  C3I  picture).  This  is  either  presented  on  a  stand-alone  display,  or  is  integrated  with 
the  ship's  combat  system  to  the  extent  that  the  organic  picture  and  C3I  picture  are 
fused.  The  commander  is  alerted  to  the  possible  presence  of  inbound  hostile  aircraft, 
well  before  weapon  release  range.  Despite  not  being  able  to  confirm  the  identity  of 
intent  of  the  aircraft  at  this  stage,  the  commander  reorients  the  task  group  about  a  new 
threat  axis,  thereby  improving  the  degree  of  protection  provided  to  the  task  group. 


Outcomes 

The  outcomes  of  applying  human-in-the-loop  simulation  in  support  of  this  application 
will  be: 

1.  Assessments  of  the  operational  utility  of  certain  types  of  information. 

2.  A  human-in-the-loop  facility  for  developing  procedures  and  tactics  that  exploit 
enhanced  information  availability. 

3.  A  test  bed  for  developing  approaches  to  integrating  new  sources  of  information  with 
the  ship's  combat  system. 
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4.  In  conjunction  with  3,  command  support  systems  may  be  demonstrated  and 
exercised  within  realistic  scenarios.  These  systems  will  support  the  execution  of  the 
new  procedures  and  tactics  that  exploit  enhanced  information  availability.  The  output 
will  be  recommendations  concerning  the  suitability  of  command  support  systems  and 
recommendations  for  their  improvement. 

It  is  noted  that  the  principal  outputs  will  be  statements  of  advice.  The  strong  emphasis 
upon  human-in-the-loop  simulation  will  generally  preclude  the  compilation  of 
traditional  measures  of  effectiveness  and  performance. 

Entities 

Within  this  scenario  the  entities  are  described  as  high-level  and  low-level.  The  high- 
level  entities  are  complex  and  composed  of  multiple  instances  of  low-level  entities 
(see  4.2). 

The  high-level  (composite)  entities  are: 

Warships 

High  value  units  (e.g.  supply/ troop  ships) 

Hostile  aircraft 
Anti-ship  cruise  missiles 
Anti-missile  missiles 
C3I  network 
JORN 

The  low-level  (component)  entities  are: 

Radar 

ESM 

IRST 

C2  system 
Human  operator 

Note:  The  C2  system  performs  functions  of  data  input,  processing  and  display.  If 
required  it  could  be  decomposed  into  such  entities. 

Intrinsic  Behaviours 

The  intrinsic  behaviours  of  the  low-level  entities  are  shown  in  Table  E-l.  The  high-level 
entities  derive  their  intrinsic  behaviours  from  the  low  level-entities  of  which  they  are 
composed.  This  in  indicated  in  Table  E-2. 
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Table  E-l:  The  low-level  (component)  entities,  their  intrinsic  behaviours,  data  inputs  and 
outputs. 


Entity 

Behaviour 

Inputs 

Outputs 

Fidelity 

Radar 

Transmits 

EM  radiation 
and  detects 
the  signal 
scattered  by 
targets  and 
the 

environment. 

Target  identity, 
position,  velocity, 
orientation  (as 
provided) 

Environmental 
parameters  (upon 
change) 

Control  commands  (as 
issued) 

Own  identity,  position, 
velocity,  orientation  (as 
required  to  maintain 
accuracy) 

Tracks  (periodic  ~1  Hz) 
System  state  data 

Med 

ESM 

Detects  EM 
emissions  of 
radars  and 
communicati 

ons 

equipment. 

Target  identity, 
position,  velocity, 
orientation  (as 
provided) 

Environmental 
parameters  (upon 
change) 

Control  commands  (as 
issued) 

Own  identity,  position, 
velocity,  orientation  (as 
required  to  maintain 
accuracy) 

Tracks  (periodic  ~1  Hz) 
System  state  data 

Med 

IRST 

Detects  EM 
emissions  of 
entities  in  the 
infrared  part 
of  the 
spectrum. 

Target  identity, 
position,  velocity, 
orientation  (as 
provided) 

Environmental 
parameters  (upon 
change) 

Control  commands  (as 
issued) 

Own  identity,  position, 
velocity,  orientation  (as 
required  to  maintain 
accuracy) 

Tracks  (periodic  ~1  Hz) 
System  state  data 

Med 

C2 

system 

Receives, 
processes, 
displays  and 
outputs  data 
Enables 
implementati 
on  of  human 
operator 
intention 

Detections,  tracks 
(periodic  ~1  Hz) 

Control  commands  (as 
issued  by  human 
operator) 

Detections,  tracks 
(periodic  ~1  Hz) 

Tactical  picture  (upon 
change) 

Recommendations  for 
action  (as  required) 
Control  commands  (as 
required,  to  warship 
components  & 
subordinate  entities) 

Med 

60 


DSTO-GD-0270 


Human 

Receives 

Tactical  picture  (upon 

Control  commands  (as 

High 

operator 

data,  views 
graphical 
representatio 
ns  of  data, 
assesses  the 
situation, 
decides  on  a 
course  of 
action  and 
implements 
it 

change) 

Recommendations  for 
action  (as  required) 

required,  to  C2) 

Table  E-2:  The  warships  (high-level/composite  entities)  derive  part  of  their  behaviour  from  their 
low-level  constituent  components. 


High  level  entity 

Behaviour  derived  from  low  level  entities 

Warship 

Transmits  EM  radiation  (Radar) 

Detects  scattered  EM  radiation  (Radar) 

Emits  EM  radiation  (IR) 

Detects  transmitted  EM  radiation  (ESM) 

Processes  data  (C2) 

Displays  data  (C2) 

Launches  weapons  (C2) 

Moves 
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Table  E-3:  The  high-level  (composite)  entities,  their  intrinsic  behaviours,  data  inputs  and 
outputs. 


Entity 

Behaviour 

Inputs 

Outputs 

Fidelity 

Warship 

Moves 
Scatters  EM 
radiation 

Own  identity, 
position,  velocity, 
orientation  (as 
required  to  maintain 
accuracy) 

Med 

High 

value 

unit 

Moves 

Scatters  EM 
radiation 
Responds  to 
movement 

control 

commands 

from 

warships 

Movement  control 
commands  (as  issued) 

Own  identity, 
position,  velocity, 
orientation  (as 
required  to  maintain 
accuracy) 

Med 

Hostile 

aircraft 

Moves 
Scatters  EM 
radiation 
Emits  EM 
radiation  in 
IR  and  as  it 
operates 
radar 
Launches 
anti-ship 
cruise 
missiles 

Own  identity, 
position,  velocity, 
orientation  (as 
required  to  maintain 
accuracy) 

EM  emission 
description 

Weapon  launch 
commands  (as 
required) 

Anti¬ 

ship 

cruise 

missile 

Moves 
Searches  for 
and  detects 
targets 

Emits  EM 
radiation  if 
RF  seeker 

Target  identity, 
position,  velocity, 
orientation  (as 
provided) 

Environmental 
parameters  (upon 
change) 

Control  commands 
(including  launch 
commands,  as  issued) 

Own  identity, 
position,  velocity, 
orientation  (as 
required  to  maintain 
accuracy) 

EM  emission 
description 

Med 
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Anti¬ 

missile 

missile 

Deploys  in 
response  to 
launch 
command 
Moves 
Receives  EM 
radiation 
scattered 
from  target 
(if  semi¬ 
active  seeker) 

Target  identity, 
position,  velocity, 
orientation  (as 
provided) 

Environmental 
parameters  (upon 
change) 

Control  commands  (as 
issued) 

Own  identity, 
position,  velocity, 
orientation  (as 
required  to  maintain 
accuracy) 

EM  emission 
description 

Med 

C3I 

network 

Provides 
data, 
including 
imagery  and 
operational 
pictures  in 
the  form  of 
tracks 

Requests  for  data  (as 
required) 

C3I  data  (as  required) 

Med 

JORN 

Transmits 

EM  radiation 
and  detects 
the  signal 
scattered  by 
targets  and 
the 

environment. 

Target  identity, 
position,  velocity, 
orientation  (as 
provided) 

Environmental 
parameters  (upon 
change) 

Control  commands  (as 
issued  by  a  human 
operator) 

Own  identity, 
position,  velocity, 
orientation  (as 
required  to  maintain 
accuracy) 

Tracks  (periodic  ~1 

Hz) 

System  state  data 

Med 
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Static  Relationships 

The  warships  are  composed  of  low-level  entities,  as  indicated  in  Table  E-4. 


Table  E-4:  The  warships  are  composed  of  low-level  entities. 


High  level  entity 

Is  composed  of  low  level  entities 

Warship 

Radar 

ESM 

IRST 

C2  system 

The  warships  exerts  command  and  control  over  the  missiles  that  they  launch.  A  single 
warship  exerts  command  and  control  over  other  warships  and  the  high  value  units. 

The  hostile  aircraft  exert  command  and  control  over  the  anti-ship  cruise  missiles  that 
they  launch. 

Interactions 

The  interactions  between  the  entities  are  shown  in  Table  E-5. 

Table  E-5:  The  interactions  between  high-level  (composite)  entities. 


Initiating  entity 

Interaction 

Receiving  entity 

Warship 

Launches 

Anti-missile  missile 

Warship 

Sends  message  (C2) 

Warship 

Warship 

Sends  message  (C2) 

High  value  unit 

Hostile  aircraft 

Launches 

Anti-ship  cruise  missile 

Anti-missile  missile 

Intercepts 

Anti-ship  cruise  missile 

Scenario  Execution 
Tasks 

The  warships  move. 

The  high  value  units  move. 

The  hostile  aircraft  move. 

The  warship  operates  radar,  ESM  and  IRST  sensors. 
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The  warship  directs  the  high  value  units. 

The  hostile  aircraft  target  the  task  group. 

The  hostile  aircraft  launch  anti-ship  cruise  missiles. 

The  warship  C2  system  receives  an  operational  picture  via  the  C3I  network. 

Tire  task  group  repositions  to  reflect  the  axis  of  attack. 

The  C2  system  receives  data  from  radar,  ESM  and  IRST. 

The  C2  system  presents  a  tactical  picture  to  the  warship  commander. 

The  C2  system  fuses  the  local  tactical  picture  and  C3I  picture. 

The  commander  decides  a  course  of  action  in  response  to  presented  data. 

The  commander  implements  a  course  of  action  through  the  functionality  provided  by 
the  C2  system. 

The  warship  launches  anti-missile  missiles. 

The  anti-missile  missile  destroys  the  anti-ship  cruise  missile. 

The  anti-ship  cruise  missile  destroys  a  warship  or  high  value  emit. 

Initial  conditions 

The  task  group  is  at  a  specified  location,  travelling  on  a  specified  course  at  a  specified 
speed.  The  arrangement  of  ships  in  the  task  group  is  specified. 

The  hostile  aircraft  are  at  a  specified  location,  travelling  on  a  specified  course  at  a 
specified  speed.  The  intent  of  the  hostile  aircraft  is  to  attack  the  task  group. 

Termination  conditions 

The  raid  by  the  hostile  aircraft  is  completed.  Either  the  anti-ship  cruise  missiles  have 
been  destroyed,  or  otherwise  rendered  harmless,  or  they  successfully  detonate  in  the 
near  vicinity  of  a  warship  or  high  value  emit. 
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Path  of 

incoming 

missile 


Path  of 

incoming 

missile 


High  V  alue  Unit  straying 
outside  defended  area  is 
unable  to  be  protected  from 
ASCIvIs  and  is  hit 


Escort  is  able  to  shoot 
down  incoming 
ASCMs  with  SAMs 
(green  dotted  arrows) 
once  they  are  within 
red  defended  area. 


High  V  alue  Units 
within  red  defended 
area  are  protected  by 
escort 


Figure  El:  The  area  that  a  single  warship  can  defend  is  a  function  of  the  expected  threat  axis. 
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Figure  E2:  A  concept  for  a  federation  that  supports  investigation  of  the  role  that  information 
available  through  the  C3I  network  may  play  in  enhancing  operational  effectiveness.  In  this  case 
EXC3ITE  provides  the  C3I  data  bus  and  the  HLA  RTI  provides  the  physical  data  bus  that 
enables  the  physical  interaction  betiveen  the  entities  to  be  modelled. 
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Appendix  F:  Land-Air  "Use"  Case 


Description 

This  environment  is  based  around  the  proposed  scenario  for  the  forthcoming  Virtual 
Air  Environment  -  LOD  experiment  which  is  to  explore  issues  of  command  and 
control  and  coordination  between  air  assets  and  a  land  task  force.  The  basic  work  is  to 
be  extended  by  the  Land  Air  Systems  task  which  is  part  of  LOD's  research  program. 
Its  aim  is  to  provide  advice  on  systems  of  systems  integration  and  operations  analysis 
to  support  the  development  of  doctrine  (and  TTPs)  plus  training  for  an  armed 
reconnaissance  helicopter  (ARH)  capability,  and  other  key  Land  Air  Systems, 
operating  as  part  of  a  combined  arms  team  in  a  Joint  operation. 

A  major  component  of  this  task  is  aimed  at  understanding  and  evolving  the  dynamic 
teaming  of  Land  Air  systems.  These  systems  include:  ARHs,  Tactical  UAVs,  GBAD, 
fixed  wing  strike,  ground  based  indirect  firepower,  and  a  range  of  ground  based  units. 
As  a  consequence  the  task  seeks  to  include  the  study  of  Joint  processes  across  the  Land 
-  Air  boundary  that  enable  teaming,  synchronisation  and  coordination  of  Land  Air 
teams. 

As  this  aim  closely  matches  some  of  the  goals  of  the  Virtual  Air  Environment  (VAE), 
much  of  the  program  of  effort  outlined  below  has  been  designed  to  meet  both  the 
requirements  of  the  Land  Air  Systems  task  and  the  VAE.  In  addition,  the  experiments 
are  designed  to  meet  the  goals  of  a  number  of  other  LOD  tasks  (Support  to  Project  Air 
87,  Land  Battlespace  Awareness,  Land  Sensor  to  Actor  Architectures)  and  have  the 
potential  to  support  some  of  the  aims  of  tasks  in  Weapons  Systems  Division,  Joint 
Systems  Branch,  and  the  Theatre  Operation  Group. 

The  key  to  this  scenario  is  that  the  entity  based  situation  creates  a  great  deal  of 
complexity  to  task  and  potentially  overload  the  human  players. 

Example  Scenario 

This  scenario  is  named  CAIRS  in  support  of  Brigade  operations. 

Kamarian  forces  have  achieved  a  political  embarrassment  for  the  Australian 
government  by  landing  a  force  (Bde-)  within  the  Australian  mainland  and  occupying 
the  town  of  Katherine.  Australian  forces  have  regained  the  Tindal  air  base  and  are  set 
to  mount  an  offensive  to  clear  Katherine  of  the  remaining  Kamarian  forces. 

The  Kamarian  air  force  continues  to  taunt  the  RAAF  with  repeated  incursions  from  the 
North  into  Australian  airspace.  The  Australian  air  defence  is  being  coordinated  from 
NORTHROC  who  are  continually  monitoring  enemy  air  tracks  being  detected  by  both 
microwave  radar  and  the  JFAS  sensor. 
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A  1TF  based  combined  Arms  Team  (CAT)  attack  is  ordered  to  secure  Katherine,  with  a 
Sqn  of  ARH  tasked  to  destroy  enemy  armour  (Tanks)  north  of  Katherine  which  would 
otherwise  become  a  support  force  for  the  main  enemy  units  within  the  township.  The 
enemy  tanks  were  spotted  by  SF  emits  in  the  area. 

The  assault  is  to  involve  a  Sqn  of  ARH  tactically  flying  to  the  NE  of  Katherine.  Prior  to 
the  ARH  engaging  the  enemy,  who  will  be  well  concealed  in  a  hide,  with  possible  shell 
scrapes  and  hard  to  acquire  whilst  stationary,  the  blue  commander  has  called  for  a 
CAIRS  mission  of  two  F/A-18  to  destroy  as  many  enemy  tanks  as  possible.  The 
intention  is  to  drive  the  remaining  tanks  from  cover  and  hence  make  them  available  for 
the  ARHs  to  defeat  in  detail. 


An  airborne  Forward  Air  Controller  (FAC)  is  to  mark  the  target  area  using  white 
phosphorous  rockets  from  a  specially  designated  pair  of  ARH.  A  RAAF  EP-3  will 
provide  electronic  suppression  to  reduce  the  danger  of  enemy  GBAD  acquiring  the 
blue  aircraft. 
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Prior  to  the  arrival  of  the  CAS  pair  of  F/A-18,  the  JFAS  detects  a  pair  of  enemy  fighters 
manoeuvring  offshore  from  Darwin.  Another  pair  of  F/A-18  is  taken  off  CAP  to 
intercept  and  ensure  safe  passage  of  the  CAS  aircraft  into  the  JFACA.  This  part  of  the 
scenario  is  to  be  provided  as  the  Air  use  case  by  AOD. 

The  CAS  pair  successfully  enter  the  Joint  Force  Air  Operations  Area  (JFAOA)/  under 
EASTROC  control  and  are  handed  over  to  the  Tactical  Air  Operations  Centre  (TAOC) 
within  the  Theatre  command.  Coordination  occurs  and  the  aircraft  are  directed  to  the 
initial  CP  (contact  point,  of  which  a  number  are  pre-defined  and  must  be  identifiable 
by  the  pilots  from  the  visuals).  Other,  low  air  movements  must  also  be  taken  into 
account  (such  as  the  ARHs  and  a  separate  Blackhawk  air-mobile  operation  to  provide 
an  infantry  coy  attack  at  Manboloo).  The  pair  then  hand-off  to  the  JOSCC  controller 
(within  the  Bde  HQ),  who  further  refines  the  mission  and  may  advise  another  CP,  for 
example  in  response  to  the  EP-3  picking  up  an  enemy  GBAD  site.  Finally  the  FAC 
takes  over  control  of  the  aircraft  and  brings  them  in,  whilst  coordinating  the  target 
marking  using  the  white  phosphorus  rockets.  The  F/A-18  pair  split,  do  their 
manoeuvre  and  exit  under  the  control  of  the  FAC,  JOSCC  and  TAOC.  Once  clear,  the 
ARH  move  in  and  defeat  any  remaining  enemy  armour. 


Figure  F-2:  Scenario. 
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Outcomes 

The  outcomes  for  this  scenario  are  to  explore  the  issues  associated  with  sharing  of 
situational  awareness  information  between  the  various  levels  of  command  and 
between  RAAF  and  Land  systems.  The  impact  of  the  extra  information  on  the  tactics, 
techniques  and  procedures  will  be  considered  and  used  to  develop  new  doctrine.  An 
important  impact  which  isn't  covered  explicitly  in  this  description  is  all  the  tasking  and 
prioritisation  which  must  occur  prior  to  the  actual  mission  commencing.  LOD  is  also 
interested  in  how  this  occurs  and  what  tools  could  be  employed  to  help. 

Entities 

There  are  many  entities  in  this  scenario  -  estimated  total  would  be  of  the  order  of  2000 
entities  within  the  constructive  environment,  with  2  virtual  ARH,  2  virtual  F/A-18, 
3  levels  of  HQ  and  a  few  virtual  sensors  (UAV  and  SF). 

Table  F-l:  Entities 


Entities 

Side 

played 

description 

ASLAV,  APC, 
light  armour,  DI 

Blue 

constructive 

Forms  the  main  advance  up  toward 
Katherine.  Will  constitute  many 

hundreds  of  entities,  all  with  sensor  and 
firepower  capabilities. 

Artillery  units 
with  fire 
locating  radar 

Blue 

constructive 

In  support  of  main  advance 

BdeHQ 

Blue 

human 

Plays  essential  roles  in  the  study.  Fed 
with  info  via  BCSS.  Special  roles  are 
GBAD  commander,  JOSCC,  Artillery 
coordination,  ACE  (air  control  element), 
TACP. 

ARH  Sqn 

Blue 

constructive 

Main  ARH  force  is  constructive 

ARH  FAC  pair 

Blue 

virtual 

Flown  in  LOD's  virtual  sim 

FAC 

Blue 

human 

Actual  FAC  in  one  of  the  virtual  ARH 

UAV 

Blue 

virtual 

Gives  virtual  UAV  pictures  back  to  HQ 

EP3-C 

Blue 

constructive 

Provides  EW  coverage  and  generates  SA 

Blackhawks 

Blue 

constructive 

Perform  airmobile  op  to  the  South 

Special  force 

units 

Blue 

constructive/ 

human 

Played  constructively,  but  human  players 
(EXCON)  use  virtual  imagery  to  feed 
intelligence  back  to  HQ 

GBAD 

Blue 

constructive 

Under  control  of  human  controller  in  HQ 

F/A-18 

Blue 

constructive 

Other  F  /  A-18  in  Stage 
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F/A-18 

Blue 

virtual 

CAIRS  pair 

see 

Blue 

human 

Played  from  EASTROC 

BRDM  +  T72 

Red 

constructive 

Enemy  armour 

Other  BRDM  + 
DI 

Red 

constructive 

Enemy  force  in  Katherine 

SA-7,  SA-16 
GBAD 

Red 

constructive 

Enemy  GBAD  sites  +  sensors 

fighters 

Red 

constructive 

Enemy  air  in  Stage 

helos 

Red 

constructive 

Enemy  support  helos 

Intrinsic  Behaviours 

If  we  focus  on  the  behaviours  of  those  entities  associated  with  the  CAIRS  mission,  the 
intrinsic  behaviours  are: 

Table  F-2:  Intrinsic  Behaviours 


Entity 

Behaviour 

Inputs 
(description, 
rate,  fidelity) 

Outputs 
(description, 
rate,  fidelity) 

Fidelity 

Detection 

GBAD  sensors 

Detects  aircraft 

Aircraft  entity 
positions 

Detections, 

tracks 

Med 

SF  units 

Detects  enemy 

Visual  (virtual) 

Reports 

Med 

UAV 

Detects  enemy 

Visual  (virtual) 

Reports 

Med 

sec 

Gives  air 

picture 

Entity 

positions 

RAP,  via  SA 
tools 

High 

JOSCC 

Coordinates 

airspace 

Entity 

positions  (SA 
tools) 

Messages, 
reports  and 

commands 

High 

EP3-C 

Detects  EW 

threats 

Entity 

positions 

Reports  and 
SA 

Med 

FAC 

Designates 
target  and 

controls  final 
engagement 

Visual  (virtual) 
and  via  SA 
tools 

Radio 

messages  to 
aircrew 

High 

Response 

F/A-18 

CAIRS  mission 

SA 

information, 

orders 

Position, 
status,  etc  via 
voice  and 

electronic 

High 

ARE!  elements 

Defeat  enemy 
tanks 

Orders 

Position, 
status,  etc 

Med 

GBAD  (red) 

Kill  blue  air 

Sensor  info 

Missile! 

Med 
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Interactions 

Table  F-3:  Interactions 


Initiating  entity 

Interaction 

Receiving  entity 

Bde  HQ 

Stands  down 

Blue  GBAD 

Bde  HQ 

Primes 

Blue  GBAD 

Bde  HQ 

Hands  over  control  of 
F/A-18 

FAC 

Bde  HQ 

Directs 

F/A-18 

EASTROC 

Hands  over  control  of 
F/A-18 

Bde  HQ 

FAC 

Directs 

F/A-18 

FAC 

Designates 

F/A-18 

UAV 

Reports 

Bde  HQ 

SF 

Reports 

Bde  HQ 

Scenario  Execution 
Initial  conditions 

Units  are  located  in  their  starting  positions 
F/A-18  are  in  the  air  above  Darwin 
Enemy  GBAD  is  active 

Terminating  conditions 

CAIRS  mission  is  complete  and  ARH  Sqn  have  defeated  enemy  armour,  or  CAIRS 
aircraft  shot  down  by  Red,  or  enemy  armour  escapes  blue  ARH. 
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Appendix  G:  Air  Architecture  "Use"  Cases 
Air  Use  Case  1 
Description 

The  purpose  of  this  environment  is  to  support  capability  development  and  acquisition  in  the 
area  of  advanced  EW  systems  for  rotary  wing  aircraft.  In  particular,  the  environment 
contributes  to  the  evaluation  of  the  military  effectiveness  of  such  systems. 

The  application  provides  a  capability  to  conduct  human-in-the-loop  simulations  with 
high  fidelity  models  of  Electronic  Warfare  Self  Protection  (EWSP)  equipment.  An 
important  component  of  such  EW  systems  is  the  operator  interface  and  this  has  a  major 
influence  on  the  application  of  successful  countermeasures  such  as  aircraft 
manoeuvres.  Through  the  inclusion  of  the  operator  in  the  simulation,  the  environment 
will  provide  a  capability  to  investigate  operator  decisions  in  respect  of  the  correct 
manoeuvre  response  required  for  a  given  situation. 

Example  Scenario 

The  scenario  is  named  Black  Hawk  Airmobile  Mission. 

An  Australian  Task  Force  has  been  deployed  to  support  a  coalition  contingent. 

An  Aviation  Regiment  (Avn  Regt)  has  been  deployed  to  the  Area  of  Operations  (AO) 
to  provide  airmobile  support  to  an  Australian  Infantry  Brigade.  The  Commander 
Australian  Theatre  has  tasked  the  Brigade  Commander  to  establish  and  secure  a  Point 
of  Entry  (POE)  airfield  to  be  used  as  the  Brigade  Maintenance  Area  (BMA). 

Reconnaissance  elements  of  a  Battalion  of  the  Royal  Australian  Regiment  (RAR)  has 
completed  a  successful  sweep  in  the  vicinity  of  the  POE  Airfield,  and  has  radioed  bacK 
to  Battalion  HQ  that  the  area  is  free  from  enemy  patrols.  The  Commander  of  the 
Aviation  Regiment  has  been  tasked  to  conduct  an  airmobile  to  insert  a  company  minus 
force,  to  secure  the  airfield  until  the  remainder  of  the  Battalion  of  the  RAR  can  be 
deployed  by  C-130  tactical  transport.  The  Commander  the  Avn  Regt  has  tasked  a 
Black  Hawk  Squadron,  with  direct  support  from  gunships,  to  plan  and  conduct  the 
activity. 

The  Air  Mission  Commander  has  received  an  intelligence  briefing  on  the  enemy's 
disposition  and  likely  intentions.  To  date  the  enemy's  activities  have  been  small-scale 
(up  to  platoon  size)  conducting  harassment/diversion  operations  in  an  attempt  to  force 
the  coalition  force  to  deploy  its  assets  away  from  enemy  concentrations. 
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The  enemy  has  anticipated  a  considerable  air  threat,  and  this  is  reflected  in  their 
Electronic  Order  of  Battle  (EOB).  The  greatest  threats  to  coalition  aircraft  within  the 
AO  are  the  radar  guided  SAM's  and  radar  guided  AAA.  Locations  of  possible  enemy 
anti-aircraft  threats  have  been  marked  on  a  map  for  mission  planning  purposes. 

The  airmobile  mission  will  be  conducted  with  four  S-70A-9  Black  Hawks  to  provide  the 
company  minus  lift,  and  a  light  fire  team  of  two  gunships  to  provide  armed  escort. 
The  formation  will  transit  in  tactical  formation  spacing  ,  via  the  planned  route.  The 
formation  of  Black  Hawks,  accompanied  by  the  light  fire  team,  will  depart  the 
squadron  location  to  the  Pick  Up  Zone  (PZ)  to  load  the  company  minus  from  the 
Infantry  Battalion.  After  the  notional  loading  time,  the  Black  Hawks  will  depart  the  PZ 
and  transit  to  the  Landing  Zone  (LZ),  in  company  with  the  light  fire  team  via  the  route 
marked  to  arrive  thirty  seconds  after  the  gunships. 

The  gunships  will  provide  cover  for  the  Black  Hawks  on  the  ground  in  the  PZ,  by 
flying  a  figure  of  eight  pattern  around  the  LZ.  After  the  notional  time  for  deplaning, 
the  Black  Hawks  will  depart  the  PZ  and  return  to  the  squadron's  home  location  via  the 
reciprocal  route. 

The  Air  Mission  Commander  has  briefed  all  the  mission  aircrew  to  conduct  SOP 
actions  on  contact  with  known  or  'pop  up'  RF  threats.  This  will  include  the 
prosecution  of  threats  by  gunship  direct  fire  support. 

Outcomes 

The  outcomes  from  this  simulation  trial  were  to  demonstrate  the  relative  impact  of 
different  EW  systems  and  their  interfaces  on  mission  effectiveness. 

Entities 

The  entities  within  this  scenario  can  be  classified  as  Virtual  Simulation  or  Constructive 
Simulation  entities. 

Table  G-l  Entities 


Entity 

Side 

Played 

Description 

Black  Hawk  HiL 

Blue 

Virtual 

Flown  in  AOD  virtual  flight  simulator 

Black  Hawk  (3  of) 

Blue 

Constructive 

Fly  formation  around  Black  Hawk  HiL 

Gunships  (2  of) 

Blue 

Constructive 

Fly  formation  around  Black  Flawk  LliL 

SAM  -  radar  guided 

Red 

Constructive 

Enemy  SAM  sites 

AAA  -  radar  guided 

Red 

Constructive 

Enemy  AAA  sites 

76 


DSTO-GD-0270 


Intrinsic  behaviours 

Table  G-2:  Intrinsic  behaviours 


Entity 

Behaviour 

Inputs 

Outputs 

Fidelity 

VIRTUAL 

Black  Hawk 

Fly  air  mobile 
mission 

EW 

information 

Position,  status 

High 

CONSTRUCTIVE 

Black  Hawks 

Maintain 
formation 
about  HiL 

Black  Hawk 

HiL  Black 

Hawk  position 

Location 

Med 

Gunships 

Maintain 
formation 
about  HiL 

Black  Hawk 

HiL  Black 

Hawk  position 

Location 

Med 

SAMs 

Kill  blue  air 

Sensor  info 

Missile 

Med 

AAAs 

Kill  blue  air 

Sensor  info 

Bullets 

Med 

Interactions 

The  interactions  among  the  entities  are: 
Table  G-3:  Interactions  among  the  entities 


Initiating  Entity 

Interaction 

Receiving  Entity 

HiL  Black  Hawk 

Dictates  other  blue  forces 
location 

Other  blue  force  air 
platfroms 

Scenario  Execution 
Tasks 

Black  Hawk  formation  is  required  to  navigate  between  Pick  Up  Zone  and  Landing 
Zone. 

Avoid  threats  where  possible. 

Survive  encounters  with  Pop-up  threats. 

Arrive  at  Landing  Zone  with  formation  intact. 

Initial  Conditions 

Black  Hawk  formation  and  escort  are  on  the  ground  at  the  Pick  Up  Zone. 


77 


DSTO-GD-0270 


Termination  Conditions 

Black  Hawk  formation  and  escort  arrive  at  the  Landing  Zone  or  HiL  Black  Hawk  is 
destroyed  by  enemy  fire. 
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Air  Use  Case  2 
Description 

The  Virtual  Air  Environment  (VAE)  is  an  Australian  Defence  Department  initiative  that  aims 
to  provide  embedded  training  capabilities  for  the  Australian  Air  Defence  System.  The  concept 
combines  live,  virtual  and  constructive  simulations,  using  distributed  simulation  to  selectively 
stimulate  core  operational  systems.  This  is  a  joint  activity  between  the  Royal  Australiati  Air 
Force  (RAAF)  and  the  Defence  Science  and  Technology  Organisation  (DSTO)  to  determine 
what  is  possible  with  current  and  emerging  technologies. 

The  initial  phase  of  the  VAE  focuses  on  Air  Defence  Controller  training.  The  vision  is  to 
extend  it  to  the  entire  Air  Defence  System  (with  similar  developments  in  the  maritime 
and  land  environments).  To  determine  the  structure  of  a  mature  VAE,  an  iterative 
approach  of  feasibility  demonstration  and  requirements  definition  is  being  used.  To 
this  end  concept  demonstrations  are  being  conducted. 

A  series  of  scenarios  has  been  developed  which  use  both  constructive  and  virtual 
simulation  to  stimulate  the  command  and  control  aspects  of  the  operational  Air 
Defence  System.  The  scenarios  are  distributed  with  players  in  different  localities.  The 
constructive  and  virtual  simulations  are  located  at  DSTO  Melbourne,  and  the 
operational  Air  Defence  Controllers  (ADCONs)  are  located  at  RAAF  Base 
Williamtown,  N.S.W 

Example  Scenario 

The  scenario  is  named  VAE_DEMO_l. 

This  scenario  is  aimed  at  providing  different  entities  on  the  ADCONs  display  and  is 
not  a  specific  tactical  scenario.  It  involves  four  virtual  entities  (at  DSTO  Melbourne) 
and  one  ADCON  (at  RAAF  Base  Williamtown).  The  virtual  entities  comprise: 

•  1  computer  generated  entity  from  STAGE  -  a  C-130  Hercules, 

•  2  computer  generated  entities  from  BattleModel  -  a  pair  of  F/ A-18  Hornets,  and 

•  1  HiL  -  a  pilot  flying  an  F/ A-18  simulator  in  the  AOSC  partial  dome. 
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The  scenario  evolves  as  shown  in  Table  G-4. 
Table  G-4:  Description  of  scenario 


Serial 

Time 

Activity 

1. 

0  mins 

The  C-130  is  flying  a  route  from  Darwin  to  Tindal. 

2. 

5  mins 

The  F/A-18  pilot  in  the  simulator  scrambles  from  Tindal. 

3. 

8  mins 

The  F/A-18  pilot  is  instructed  by  the  ADCON  to  intercept  the 
C-130. 

4. 

20  mins 

Two  BattleModel  F/A-18  aircraft  take  off  from  Tindal. 

5. 

24  mins 

The  F/A-18  pilot  is  told  by  the  ADCON  to  intercept  the  two 
F/A-18S. 

6. 

35  mins 

The  pilot  intercepts  the  F/ A-18s 

The  pilot  visually  identifies  the  C-130  and  F/A-18  aircraft  at  each  intercept  and  the 
scenario  concludes  with  the  identification  of  the  two  BattleModel  generated  F/ A-18s. 
The  scenario  can  be  expanded  to  include  50  virtual  entities  (25  each  from  BattleModel 
and  STAGE)  with  up  to  8  (consisting  of  pairs  of  F/A-18s  each  from  BattleModel  and 
STAGE)  able  to  be  controlled  by  an  ADCON.  Other  aircraft  involve  a  mixture  of 
civilian  and  military,  light  and  commercial  categories.  The  entities  are  located  in  the 
Darwin-Tindal  area 

Outcomes 

The  outcome  of  this  exercise  is  to  demonstrate  that  an  ADCON  has  the  appropriate 
Situation  Awareness  Display  to  be  able  to  control  the  simulated  (as  well  as  real  world) 
entities.  This  exercises  the  command  and  control  system. 

Entities 

The  entities  within  this  scenario  can  be  classified  as  Live,  Virtual  or  Constructive 
Simulation  entities. 

The  Live  Simulation  entities  are: 

•  Air  Defence  Controllers  (ADCONs)  and  selected  parts  of  the  Air  Defence  System 
The  Virtual  Simulation  entities  are: 

•  F/A-18  HiL  simulator  with  high  field-of-view  visuals 
The  Constructive  Simulation  entities  are: 

•  C-130  (generated  by  STAGE) 

•  F/A-18  (generated  by  BattleModel  and  STAGE) 
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•  Commercial  aircraft 

•  Light  aircraft 

Scenario  Execution 

Table  G-5:  Summary  of  activities  which  can  be  undertaken  with  respect  to 

VAEJDEMOJI. 


Activity 

Description 

Rehearsal 

All  entities  start  at  t=0  minutes  and  continue  until  the  end 
of  scenario  (t=35  minutes). 

Demonstration 

HiL  and  STAGE  start  at  t=0  minutes. 

BattleModel  CGFs  start  at  t=20  minutes. 

STAGE  CGF  stopped  at  t=20  minutes. 

Test  1 

This  includes  up  to  30  entities  and  comprises:  one  HiL, 
nine  STAGE  generated  C-130s,  and  20  BattleModel 
generated  F/A-18s.  Partway  through  this  test,  one  circling 
F/A-18  will  be  generated  using  VR-Link  from 
Williamtown. 

Test  2 

This  includes  up  to  50  entities,  and  comprises:  no  HiL,  29 
STAGE  generated  C-130s,  20  BattleModel  generated  F/A- 
18s  and  one  circling  F/A-18  generated  using  VR-Link  from 
Williamtown. 

Experimental  Description 

The  main  demonstration  takes  place  at  3CRU  where  the  Phoenix  display  is  located,  and 

consists  of: 

•  an  Air  Defence  Controller  at  the  Phoenix  Display  (which  shows  actual  air  traffic  as 
well  as  the  four  virtual  entities),  communicating  with  the  pilot  in  the  F/  A-18  flight 
simulator  to  facilitate  his  intercepts  with  the  artificial  entities, 

•  a  PC  running  Microsoft  NetMeeting  software  which  allows  the  visual  scene  in  the 
AOSC  partial  dome  display  to  be  viewed.  Later  this  PC  is  used  to  generate  a 
virtual  entity  (a  circling  F/A-18)  which  is  displayed  on  all  systems  (Test  1  and 
Test  2), 

•  a  situation  awareness  display  which  shows  a  plan  view  of  the  location  of  all  virtual 
entities, 

•  Stealth,  a  DIS  utility  that  shows  the  outside  view  as  would  be  seen  by  a  simulated 
entity. 

The  DIS-DTE  gateway  software  is  located  on  a  PC  at  3CRU. 

At  AOD,  DSTO,  Fishermans  Bend,  the  set  up  in  the  AOSC  comprises: 

•  a  video  screen  of  the  pilot  in  the  F/A-18  cockpit  in  the  partial  dome  display. 
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•  the  STAGE  screen,  showing  the  location  of  all  virtual  entities, 

•  the  BattleModel  screen  and  BattleView,  showing  the  location  of  all  virtual  entities, 

•  a  situation  awareness  display  (same  as  at  3CRU), 

•  a  Phoenix  screen,  showing  all  four  virtual  entities  (but  no  actual  air  traffic), 

•  an  intercom  allowing  voice  communications  between  the  ADCON  and  the  pilot  to 
be  heard, 

•  a  projector  showing  the  image  of  the  pilot  in  the  partial  dome,  and 

•  a  displayed  outline  of  the  scenario  and  its  evolution. 

The  pilot  in  the  F/A-18  simulator  with  partial  dome  display  is  located  in  the  next 
room.  The  pilot  communicates  with  the  Air  Defence  Controller  via  a  standard  phone 
line.  The  DIS  logger  and  the  UNIX  utility  "tcpdump"  are  used  to  capture  DIS  and 
network  data  traffic  for  later  analysis. 

Appearance  Of  Entities 

Four  virtual  entities  will  appear  correctly  (geographic  position,  speed,  altitude,  etc.)  on 
the  3CRU  Phoenix  display  system  in  Williamtown  alongside  normal  air  traffic 
movements. 

There  were  several  other  displays  which  show  the  evolution  of  the  scenario.  A 
Phoenix  display  screen,  also  set  up  in  the  AOSC  control  centre,  shows  only  the 
simulated  virtual  entities  participating  in  the  scenario,  whereas  the  real  system  will 
also  show  normal  air  traffic  movements. 

STAGE  will  receive  all  DIS  PDUs,  and  consequently  display  the  F/ A-18  pilot  in  the 
partial  dome  simulator,  the  two  BattleModel  generated  F/A-18s,  and  its  own  C-130,  on 
its  situation  awareness  display. 

The  BattleModel  viewer,  BattleView,  is  also  able  to  display  all  incoming  PDUs  and 
shows  the  position  of  the  pilot  in  the  F/A-18  simulator,  the  C-130  generated  by  STAGE 
as  well  as  the  two  F/A-18s  generated  by  BattleModel. 

The  AOSC  control  centre  has  a  situation  awareness  display  which  will  also  show  all 
four  virtual  entities.  This  situation  awareness  display  is  also  available  at  RAAF 
Williamtown. 

The  pilot  visually  identifies  the  C-130  and  F/A-18  aircraft  at  each  intercept,  and  the 
scenario  concludes  with  the  identification  of  the  two  BattleModel  generated  F/A-18s. 
The  scenario  lasts  a  total  of  35  minutes. 
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Measures 

Table  G-5  presents  various  measures  as  each  stage  of  the  scenario  is  executed.  The 
various  stages  in  the  scenario  are  identified  together  with  their  function  and  subjective 
and  objective  measures.  The  last  column  provides  a  summary  of  the  outcome. 

For  the  scenario  to  evolve  as  expected,  the  gateway  must  pass  the  virtual  entities  to  the 
tracking  computer  (MV  15000),  which  then  converts  them  for  display  on  the  Phoenix 
system.  All  sites  should  observe  the  virtual  entities  at  the  appropriate  times  with  the 
appropriate  characteristics. 

The  purpose  of  the  first  serial  is  to  verify  data  connectivity,  correct  radar  operation, 
and  receipt  of  a  DIS  entity  at  the  gateway  with  subsequent  conversion  to  DTE  format. 
The  gateway  should  show  the  presence  of  a  single  DIS  entity  (the  STAGE  generated  C- 
130)  and  indicate  that  the  entity  is  in  range.  Plots  for  the  entity  are  displayed  on 
Phoenix  and  a  track  should  be  formed  by  the  tracking  computer. 

The  second  stage  involves  adding  another  virtual  entity  (the  pilot  in  the  F/A-18 
simulator)  and  confirming  that  the  new  entity  is  received  at  both  the  3CRU  and  DSTO 
sites.  A  comparison  of  position  information  at  both  sites  should  show  the  information 
to  be  the  same. 

The  third  stage  involves  the  pilot  being  directed  by  the  ADCON  to  intercept  the  C-130. 
The  ADCON  directs  the  intercept  so  that  the  F/A-18  radar  detects  the  C-130  as 
expected.  The  ADCON  controllers'  calls  giving  azimuth  and  range  should  comply 
with  readouts  from  the  gateway. 

The  fourth  stage  involves  the  injection  of  two  more  virtual  entities  (the  two 
BattleModel  F/A-18s).  These  will  be  observed  on  the  gateway  and  all  displays 
(Phoenix,  STAGE,  BattleModel,  and  the  two  situation  awareness  displays  at  3CRU  and 
the  AOSC)  and  should  show  the  four  entities  (one  C-130,  one  HiL  F/A-18,  two  x 
BattleModel  F/A-18s). 

In  stage  five,  the  HiL  pilot  in  the  F/A-18  simulator  is  directed  to  intercept  the  two 
BattleModel  generated  F/ A-18s. 

The  sixth  stage  is  the  conclusion  of  the  scenario.  The  outcome  should  be  a  successful 
intercept.  This  scenario  demonstrates  that  multi-player,  multi-radar,  dissimilar  levels 
of  simulation  are  possible. 
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Appendix  H:  Distributed  Simulation  Standards 

Background  on  DIS 

Distributed  Interactive  Simulation  is  a  simulation  interoperation  standard  developed 
from  the  earlier  SIMNET  work  carried  out  in  the  US. 

DIS  is  a  broadcast  protocol,  where  information  is  sent  via  UDP  to  all  nodes  typically 
within  a  given  subnet.  The  DIS  standard  defines  a  number  of  categories  of  messages, 
called  Protocol  Data  units  (PDU),  including: 

•  Entity  state  PDU  (ESPDU),  containing  the  location,  directional  vectors  and 
appearance  codes  for  an  individual  entity. 

•  Fire  PDU,  sent  whenever  a  weapon  fires.  This  is  used  to  generate  the  visual 
appearance  of  a  flash  on  visual  'stealth'  viewers. 

•  Detonation  PDU,  generated  whenever  the  previously  fired  projectile  (which  may  be 
modelled  using  entity  state  PDU's  or  not,  depending  on  whether  it  was  a  missile  or 
a  bullet,  shell,  etc)  has  been  modelled  to  have  reached  its  detonation  point.  In 
response  to  the  detonation  PDU,  the  target  must  calculate  its  damage  and  update 
this  to  the  rest  of  the  network  in  its  next  entity  state  PDU. 

There  are  other  specialised  PDU  types,  including  signal  PDUs,  used  to  model 
electromagnetic  emissions  and  to  send  messages,  communication  (voice)  PDUs  for 
sending  digitised  voice  and  others  relating  to  special  domains,  such  as  underwater 
propagation  modelling,  etc.  However  for  the  majority  of  entity  based,  real-time 
simulations,  the  bulk  of  the  DIS  traffic  is  composed  of  the  three  main  PDUs  detailed 
above. 

The  other  key  ingredient  in  the  DIS  standard  is  the  definition  of  a  number  of  dead¬ 
reckoning  algorithms  used  to  reduce  the  frequency  of  ESPDUs  being  broadcast.  Any 
simulation  entity  must  broadcast  an  ESPDU  at  least  once  every  5  seconds,  or  it  is 
assumed  to  have  dropped  off  the  network.  However  they  must  also  broadcast  an 
ESPDU  when  they  have  diverged  from  their  current  dead-reckoned  position  by  more 
than  a  certain  error  factor.  In  this  way,  other  simulators  can  keep  track  of  the  entity  at 
whatever  time-step  it  requires  for  its  internal  modelling  by  dead  reckoning  from  the 
last  known  (ESPDU)  position.  This  approach  allows,  for  example,  visual  stealth 
viewers  that  typically  refresh  the  display  at  30-60Hz  to  smoothly  extrapolate  the 
position  of  the  drawn  models  between  frames  despite  the  fact  that  the  ESPDUs  may 
arrive  at  far  less  frequent  intervals. 

The  DIS  standard  also  defines  a  complete  range  of  enumeration  values  corresponding 
to  various  country,  platform  and  weapon  types. 
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Background  on  HLA 

High  Level  Architecture  (HLA)  is  a  methodology  designed  to  support  distributed 
simulation  exercises.  It  has  been  mandated  by  the  US  DoD  as  the  replacement  for  both 
DIS  and  ALSP  (Aggregate  Level  Simulation  Protocol),  a  networking  protocol  used  for 
connecting  wargames.  HLA  development  is  sponsored  by  the  US  Defense  Modeling 
and  Simulation  Office  (DMSO). 

HLA  has  been  under  development  since  1995.  On  September  21  2000,  the  Standards 
Board  of  the  Institute  of  Electronic  and  Electrical  Engineers  (IEEE)  voted  to  accept  the 
HLA  as  an  international  standard.  When  the  IEEE  standardisation  process  is 
completed,  there  will  be  three  new  standards:  (1)  1516  -  Framework  and  rules;  (2) 
1516.1  -  Federate  interface  specification;  and  (3)  1516.2  -  Object  Model  Template. 

The  HLA  is  not  a  protocol  based  standard  like  DIS,  but  is  a  set  of  high-level  rules  to 
which  a  set  of  interconnecting  simulations  and  simulators  (known  as  a  federation  of 
federates  in  HLA  parlance)  must  adhere.  In  essence  the  rules  specify  that: 

•  Each  of  the  federates  must  all  define  (and  document)  a  Simulation  Object  Model 
(SOM)  specifying  what  they  are  able  to  share  and  receive  from  the  rest  of  the 
federation. 

•  The  federation  must  have  a  documented  Federation  Object  Model  (FOM),  basically 
a  composite  of  all  the  individual  FOMs. 

•  Each  federate  must  communicate  through  a  middleware  component  known  as  the 
run-time  infrastructure  (RTI).  The  definition  of  the  RTI  calls  is  part  of  the  HLA 
specification,  however  the  implementation  of  the  RTI  isn't  and  there  exists  an 
number  of  alternative,  incompatible  RTIs. 

The  key  to  understanding  HLA  is  that  the  simulations  to  be  connected  (federates)  must 
all  be  capable  of  understanding  elements  of  each  others  SOMs.  Each  SOM  is  an  object- 
oriented  like  definition  of  what  objects  the  federate  represents,  what  the  values  related 
to  that  federate  are  able  to  be  published  for  use  by  others,  or  subscribed  to  if  it  is  being 
picked  up  from  another  federate  and  what  classes  of  interactions  the  federate  will 
support.  Thus  each  FOM  must  be  compatible  with  other  federates  FOMs.  This  relates 
not  only  to  the  naming  of  objects  (simulation  A  must  use  the  same  name  for  an  entity 
as  simulation  B),  but  also  to  the  rules  of  how  to  represent  data,  how  to  implement  dead 
reckoning,  who  determines  damage  and  what  constitutes  a  given  interaction.  Unlike 
DIS,  HLA  does  not  define  any  of  these  conventions  and  it  is  left  to  the  federation 
designers  to  resolve  these  issues. 

The  strict  requirement  to  predefine  all  objects  and  interactions  and  to  subscribe  and 
publish  to  these  permits  the  RTI  to  be  far  more  efficient  in  its  delivery  of  data  than  the 
crude  broadcast  seen  in  DIS.  The  RTI  is  able  to  determine  which  federate  needs  to  be 
sent  which  piece  of  information  and  hence  significantly  reduce  the  overall  network 
load.  Additional  filtering  based  on  data  ranges,  such  as  location  further  allows  the  RTI 
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to  avoid  delivering  data  to  a  federate  which  is  unconcerned  with  it.  As  a  result,  HLA 
will  in  theory  allow  far  more  scalable  networks  of  federations  to  be  developed  than 
was  possible  in  the  network  bounded  DIS  model. 

Another  benefit  of  HLA  as  compared  to  DIS  is  the  support  for  time  constrained 
federations  to  allow  simulations  operating  in  different  time  steps  to  still  interoperate 
efficiently.  This  would  be  particularly  applicable  to  closed,  analytical  simulations  or  to 
physics  based  engineering  models  which  may  not  operate  in  wall-clock  based  'real- 
time'. 
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Appendix  I:  Virtual  Ship  Architecture  Working 
Group  (VSAWG)  Terms  of  Reference  21  May  1999 

The  role  of  the  Virtual  Ship  Architecture  Working  Group  (VSAWG)  is  to  determine, 
document  and  evolve  the  architecture  of  the  Virtual  Ship.  Having  established  a 
baseline  version,  the  VSAWG  will  evolve  the  Virtual  Ship  architecture  in  order  to 
maximise  the  utility  of  the  Virtual  Ship.  The  Virtual  Ship  architecture  will  be  subject 
to  configuration  control. 

The  VSAWG  will  operate  in  a  consultative  manner  and  ensure  that  the  technical 
content  of  the  architecture  is  guided  by  the  requirements  of  the  user  community. 
Ultimate  responsibility  for  the  content  of  the  architecture  will  reside  with  the  VSAWG. 

The  architecture  of  the  Virtual  Ship  will  be  based  upon  the  High  Level  Architecture 
(HLA)+.  Models  of  system  components  will  be  the  federates  of  a  HLA  federation.  The 
federation  will  be  described  by  the  Virtual  Ship  FOM  (VS-FOM),  and  the  development 
of  this  will  be  the  principal  task  of  the  VSAWG. 

Elements  of  the  Virtual  Ship  Architecture  (VS A) 

The  Virtual  Ship  will  be  constructed  in  accordance  with  the  High  Level  Architecture.  In 
addition,  the  specific  objective  of  simulating  warship  operations  necessitates  addition 
to,  or  specialisation  of,  the  HLA.  This  collection  of  additions  and  specialisations  will 
constitute  the  Virtual  Ship  Architecture  (VSA). 

There  will  be  five  essential  elements  of  the  VSA.  These  are  described  as  follows. 

The  VS-FOM 

This  defines  the  data  exchange  contract  amongst  the  federates  that  constitute  the 
Virtual  Ship.  It  will  be  constructed  in  accordance  with  the  Object  Model  Template 
(OMT). 

The  Virtual  Ship  Lexicon 

The  objects,  attributes,  interactions  and  parameters  within  the  VS-FOM  will  form  the 
Virtual  Ship  lexicon.  The  lexicon  will  provide  for  common  terminology  use  across 


+  The  High  Level  Architecture  is  a  framework  for  performing  distributed  simulation.  A  number  of 
simulation  models,  known  as  federates,  operate  together  to  create  a  common  simulated  environment.  The 
collection  of  all  federates  is  known  as  the  federation.  In  order  to  operate  together  the  federates  must 
exchange  information.  The  data  exchanged  amongst  federates  is  described  by  the  Federation  Object  Model 
(FOM).  The  structure  of  the  FOM  is  determined  by  the  federation  developer  and  federates  must  be 
engineered  to  exchange  data  in  accordance  with  it.  The  format  of  the  FOM  is  given  by  the  Object  Model 
Template  (OMT).  This  is  a  tabular  format  that  details  the  objects  within  the  federation,  the  attributes  that 
describe  them,  and  the  interactions  amongst  the  objects  which  are  described  by  parameters. 


91 


DSTO-GD-0270 


modelling  applications.  It  is  through  the  common  interpretation  of  data  that  a  common 
world  view  can  be  established  amongst  distributed  federates. 

The  Virtual  Ship  Rules 

The  Virtual  Ship  rules  will  describe  mandatory  characteristics  of  federates  brought  into  the 
Virtual  Ship,  over  and  above  the  HLA  rules. 

Virtual  Ship  Data  Standards 

Different  modelling  applications  relevant  to  the  Virtual  Ship  have  shared  interest  in 
data.  The  provision  and  exploitation  of  this  data  will  be  facilitated  through 
establishment  of  common  data  standards. 

The  Virtual  Ship  Tools 

A  variety  of  existing  tools  will  support  development  of  the  Virtual  Ship.  In  addition  to 
tools  that  support  the  HLA  generally,  a  requirement  for  additional  tools  can  be 
foreseen.  These  will  support  scenario  generation  and  control,  federate  development, 
object  model  consistency  checking,  federate  monitoring  including  stealth  viewing  and 
federation  execution  management  and  analysis. 

Outputs 

The  VSAWG  will  produce  the  following: 

1.  A  VS-FOM  documented  in  accordance  with  the  HLA  OMT, 

2.  A  report  describing  the  principal  elements  of  the  VS  A,  with  particular  reference  to 
the  VS-FOM, 

3.  A  document  describing  the  manner  in  which  the  VS-FOM  will  evolve,  including 
configuration  control, 

4.  A  series  of  working  papers  documenting  the  technical  considerations  on  topics  of 
relevance  to  whole  ship  simulation, 

5.  A  technical  brief  on  the  VSA,  which  is  public  release, 

6.  A  non-technical  brief  on  the  VSA,  which  is  public  release. 

Key  tasks 

The  essential  element  of  the  VSA  is  the  VS-FOM.  Construction  of  this  will  drive  activity 
related  to  the  other  four  aspects  of  the  VSA.  The  task  in  constructing  the  VS-FOM  is  to 
determine  the  objects  that  will  be  represented  in  the  Virtual  Ship  from  a  data  exchange 
point  of  view,  and  the  interactions  amongst  the  federates.  In  the  lexicon  of  the  HLA  the 
objects  are  described  by  their  attributes  and  interactions  are  described  by  their 
parameters. 
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The  tasks  that  must  be  performed  by  the  VSAWG  in  order  to  capture  these  data  are  to: 

1.  Identify  the  ship  components  that  will  be  modelled  and  the  interactions  amongst 
them, 

2.  Identify  the  requirement  for  data  exchange  with  the  outside  world,  or  the  scenario, 

3.  Determine  a  set  of  objects  and  interactions  that  capture  this  requirement, 

4.  Determine  the  attributes  and  parameters  of  the  objects  and  interactions, 

5.  Determine  a  lexicon  of  objects,  interactions,  attributes  and  parameters, 

6.  Determine  mandatory  requirements  (rules)  for  federates  to  participate  in  the 
Virtual  Ship  federation  executions, 

7.  Define  key  enumerated  data  types  and  complex  data  types, 

8.  Construct  the  VS-FOM,  exploiting  object  and  interaction  class  hierarchies, 

9.  Assess  the  VS-FOM  for  robustness  with  respect  to  the  introduction  of  new 
attributes,  higher  fidelity  models,  lower  fidelity  models,  new  object  classes  and  new 
interaction  classes, 

10.  Identify  common  data  requirements  across  simulation  applications, 

11.  Identify /specify  software  tools  that  will  assist  in  the  development  of  simulation 
models  that  are  compliant  with  the  VS-FOM. 

Process 

The  VSAWG  will  meet  on  a  regular  basis,  at  an  interval  to  be  determined  by  the 
members.  Additional  meetings  may  be  called  as  required.  Meetings  of  the  full  VSAWG 
are  intended  primarily  as  a  mechanism  for  providing  rigorous  consideration  of 
architecture  proposals  and  decision  making  concerning  these. 

The  bulk  of  the  technical  work  involved  in  formulating  the  Virtual  Ship  Architecture 
will  occur  out  of  session.  A  number  of  subcommittees  will  be  formed  in  order  to 
address  the  data  exchange  requirement  amongst  models  of  various  ship  systems.  For 
example,  a  subcommittee  may  be  formed  to  consider  radar  modelling  and  another  to 
consider  above  water  weapons.  There  will  be  cross  membership  of  subcommittees  to 
exploit  system  commonalities.  For  example,  passive  sonar  and  ESM  share  many 
similarities  and  their  joint  consideration  offers  the  prospect  of  accelerated  progress. 

The  outcome  of  subcommittee  deliberations  will  be  a  series  of  working  papers.  These 
might  be  profitably  published  as  DSTO  Technical  Notes,  with  due  recognition  of 
Industry  contributions. 

These  findings  shall  be  brought  together  by  the  VSAWG  in  order  to  determine  the 
Virtual  Ship  Architecture.  The  full  VSAWG  will  subject  the  architecture  proposals  of 
the  subcommittees  to  rigorous  analysis,  particularly  with  respect  to  the  issue  of 
robustness  as  noted  above. 
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Appendix  J:  Glossary  of  Acronyms  and  Terms 


AAA 

Anti  Air  Artillery 

ADCON 

Air  Defence  Controller 

ADF 

Australian  Defence  Force 

ADO 

Australian  Defence  Organisation 

ADS 

Advanced  Distributed  Simulation 

ADSO 

Australian  Defence  Simulation  Office 

AEW&C 

Airborne  early  Warning  and  Control 

AIO 

Australian  Imagery  Organisation 

AO 

Area  of  Operations 

AOD 

Air  Operations  Division 

AOIM 

Area  of  Interest  Manager 

AOSC 

Air  Operations  Simulation  Centre 

ASCM 

Anti  Ship  Cruise  Missile 

ATM 

Asynchronous  Transfer  Mode 

BMA 

Brigade  Maintenance  Area 

C2 

Command  and  Control 

C3I 

Command,  Control,  Communications,  and  Intelligence 

C4ISR 

Command,  Control,  Communications,  Comp 
Information,  Search  &  Reconnaissance  ??? 

CATDC 

Combined  Arms  Training  and  Development  Centre 

CD 

Communications  Division 

CGF 

Computer  Generated  Forces 

CORBA 

Common  Object  Request  Broker  Architecture 

COTS 

Commercial  Off  The  Shelf 

DCOM 

Distributed  Component  Object  Model 

DDG 

Guided  Missile  Destroyer 

DERA 

Defence  Evaluation  Research  Agency 

DICE 

Distributed  Interactive  C3I  Environment 

DIE 

Defence  Information  Environment 

DIS 

Distributed  Interactive  Simulation 

DMSO 

Defense  Modeling  and  Simulation  Office  (US) 

DoD 

US  Department  of  Defense 

DSAF 

Defence  Simulation  Advisory  Forum 

DSTO 

Defence  Science  &  Technology  Organisation 

EMPDU 

Emission  PDU 

EOB 

Electronic  Order  of  Battle 

ESPDU 

Entity  State  PDU 

EW 

Electronic  Warfare 

EWD 

Electronic  Warfare  Division 

EWPA 

Electronic  Warfare  Program  Arrangement 

EWSP 

Electronic  Warfare  Self  Protection 

EXC3ITE 

Experimental  C3I  Technology  Environment 

FFG 

Guided  Missile  Frigate 
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FOM 

GBAD 

GOTS 

HiL 

HLA 

HQ 

HQADF 

HQAST 

IEEE 

IMAD 

IP 

ISDN 

ITD 

J2EE™ 

JOD 

JORN 

JSB 

JSE 

LAN 

LOD 

LZ 

MANIFOLD 

M&S 

MGI 

MOD 

ModSAF 

MSEB 

MWTC 

OPFOR 

PA10 

PDU 

POE 

PZ 

QoS 

RACE 

RAAF 

RAN 

RAR 

RF 

RID 

RMI 

RPR-FOM 

RTI 

RTM 


Federation  Object  Model 
Ground  Based  Air  Defence 
Government  Off  The  Shelf 
Human-  in-the- Loop 
High  Level  Architecture 
Headquarters 

Headquarters,  Australian  Defence  Force 
HQ  Australian  Theatre 

Institute  of  Electrical  and  Electronic  Engineers 
Imagery  Management  and  Dissemination 
Internet  Protocol 

Integrated  Services  Digital  Network 
Information  Technology  Division 
Java  2  platform  Enterprise  Edition 
Joint  Operations  Division 
Jindalee  Operational  Radar  Network 
Joint  Systems  Branch 
Joint  Synthetic  Environment 
Local  Area  Network 
Land  Operations  Division 
Landing  Zone 

MANagement  of  Information  by  the  Federation  OF  Logical 
Data 

Modelling  and  Simulation 

Military  Geographic  Information 

Maritime  Operations  Division 

Modular  Semi  Automated  Forces 

Military  Systems  Experimentation  Branch 

Maritime  Warfare  Training  Centre 

Opposition  Forces 

Project  Arrangement  10 

Protocol  Data  Unit 

Point  of  Entry 

Pickup  Zone 

Quality  of  Service 

Rapid  Application  Construction  Environment 

Royal  Australian  Air  Force 

Royal  Australian  Navy 

Royal  Australian  Regiment 

Radio  Frequency 

RTI  Interface  Definition 

Remote  Method  Invocation 

Real  time  Platform  Reference  FOM 

Run  Time  Infrastructure 

Requirements  Traceability  Matrix 
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SAM 

Surface  Air  Missile 

SEDRIS 

Synthetic  Environment  Data  Representation  and  Interchange 
Specification 

SERF 

Synthetic  Environment  Research  Facility 

SIMNET 

Simulator  Networking 

SOM 

Simulation  Object  Model 

SOP 

Standard  Operating  Procedures 

SSD 

Surveillance  Systems  Division 

STAGE 

Scenario  Tactical  And  Generation  Environment 

TBS 

Theatre  Broadcast  System 

TCP 

Transmission  Control  Protocol 

TOB 

Theatre  Operations  Branch 

TTCP 

The  Technical  Cooperation  Program 

UDP 

User  Datagram  Protocol 

USN 

United  States  Navy 

VAE 

Virtual  Air  Environment 

WAN 

Wide  Area  Network 
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Glossary  of  Terms 

The  definitions  herein  are  not  intended  to  be  rigorous;  important  features  of  one  M&S 
category  frequently  overlap  those  of  another  since  the  degree  of  human  participation 
and  the  degree  of  equipment  realism  are  infinitely  variable.  With  this  caveat,  the 
following  are  generally  accepted  terms  and  definitions  for  the  more  important  models 
and  simulations  relevant  to  Defence. 

Model.  A  physical,  mathematical  or  otherwise  logical  representation  of  a  system, 
entity,  phenomenon  or  process. 

Simulation.  The  operation  or  exercise  of  a  model  over  time. 

Modelling  and  Simulation  (M&S).  The  term  refers  to  the  use  of  models,  including 
emulators,  prototypes,  simulations,  simulators,  stimulators,  either  statically  or  over 
time,  to  develop  data  as  a  basis  for  making  managerial  or  technical  decisions.  The 
terms  "modelling"  and  "simulation"  are  often  used  interchangeably. 

Analytical  domain: 

-  The  majority  of  simulation  models  are  employed  in  imitating  the  behaviour  of 
physical  systems  (such  as  aircraft  or  missiles)  which  do  not  require  or  involve 
interactive  human  input.  Simulations  which  require  the  aggregation  of  many 
systems  involving  human  behaviour  (such  as  air  combat)  may  employ 
mathematical  representations  of  human  operators  as  well  as  of  the  physical 
systems.  These  models  are  employed  in  the  systematic  study  of  the  behaviour  and 
capabilities  of  complex  systems. 

Human  interactive  domain: 

-  Live.  A  representation  of  military  operations  using  military  personnel  and 
equipment  which  simulate  experiences  achieved  during  actual  operational 
conditions.  Live  simulation  participants  perceive  the  environment  via  actual 
sensors  or  directly  with  their  own  eyes. 

-  Virtual.  A  simulation  involving  real  people  operating  simulated  systems.  The 
human-in- the-loop  in  virtual  simulations  has  a  central  role  through  the  exercise  of 
motor  control  skills  (e.g.,  flying  an  aircraft),  decision  skills  (e.g.,  committing  fire 
control  resources  to  action),  or  communication  skills  (e.g.,  as  members  of  a  C4I 
team). 

-  Constructive.  Models  and  simulations  that  involve  real  people  making  inputs  into 
a  simulation  that  carries  out  those  inputs  by  simulated  people  operating  simulated 
systems.  Wargames,  models  and  analytical  simulations  that  typically  involve 
aggregated  software  representations  of  units,  their  behaviour  and  associated 
outcomes. 

Hardware-in-the-loop  domain:  Simulations  that  involve  actual  hardware  components 
of  military  systems  (e.g.,  a  missile  seeker  head)  integrated  with  simulations  of  the 
other  components  of  the  overall  system. 
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Simulation  Based  Acquisition.  A  process  involving  an  integrated  application  of 
M&S  that  supports  military  systems  from  initial  concept  development  through  the 
acquisition  phase  to  in-service  support. 

Synthetic  Environment.  Computer  generated  representation  of  the  real  world.  Most 
often  used  to  recreate  a  virtual  battlefield  in  which  simulations  linked  via  networks  can 
conduct  and  fight  a  highly  realistic  battle. 
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